Maintainer Documentation

You are here: Home > Maintainer Documentation

---

Welcome to the PIConGPU Maintainer section of our wiki! We collect administrative tasks and policies here.

Dependency Changes

The workflow to update PIConGPU dependencies is documented in this page. Please make sure all according places are update before accepting PRs!

General Topics and To Do's

• How to "Code Review": See the Code Review guide
• Labels for pull requests and issues
• Compile Suite Documentation
• Policies for acknowledgements and co-authors in PIConGPU releated publications

How to Draft a new Release

update version names/numbers

• PIConGPU: src/picongpu/include/version.hpp
• sphinx (rtd) docs: ./docs/source/conf.py
• future: (all CMakeLists.txt: project(... VERSION X.Y.Z LANGUAGES CXX))

see semver.org

check & update dependencies

• are all dependencies in their minimal and latest stable release version working?
• are included/shipped thirdParty dependencies up-to-date?

check documentation

• is readthedocs still building successfully?
• after release, enable the new version so it can be selected by users

how to collect & write the change log

• create a release branch from dev: git checkout -b release-<to-be-tag-name>
• get all logs from git log --oneline --graph --decorate --first-parent master.. in dev oder release-X.Y.Z
• read the issues related to it and group bugs/features/misc
• now compare the changes in .param and .unitless files again, make sure they are highlighted in the change log: cd src/picongpu/include/simulation_defines/ ; git diff master.. .
• find related issues with git blame <pathToParam-File> - use the commits sha to search for the issue on GitHub (use the top row search bar) or via git log <sha> todo: write a script that finds the associated pulls itself
• maybe https://github.com/skywinder/github-changelog-generator can help us?
• mention all authors that contributed to this release: git log lastReleaseTag.. --format="%aN <%aE>" --reverse | sort -u or sorted by commits git shortlog --no-merges -s -n [-e] lastReleaseTag..
• commit the change log
• publish the release branch and "wait" for further bug fixes only
• start a pull request to master (ideally, this should be a fast-forward, but we will force a merge commit via --no-ff)
• tag the new commit in master and sign this tag (see below)
• release on Zenodo
  • revision: same authors as last stable release + bugfix authors
  • major release: all authors that contributed
  • meta: add EU fundings, cross-link via DOI previous release (and in previous release: this new release)
• add Zenodo DOI badge to release description (disable its webhook for that step to avoid dbl release)
• sync back the change log and version changes to dev with a new pull request from master

port the pre-release wiki changes

Port the wiki changes from the Pre-Release-Content pages in the wiki. Remember to fix the title, i.e. remove any PR: prefix.

back porting bug fixes

• minimal changes (no API/.param changes)
• create a revision for 1 to N combined fixes (the Z in the X.Y.Z version number)