Skip to content

Maintainer Documentation

Sergei Bastrakov edited this page Dec 1, 2021 · 30 revisions

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 Draft a new Release

update version names/numbers

Use the src/tools/bin/newVersion.sh script for updating all versions!

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

When the next release branch for master is opened from dev, updated the dev branch to the next (expected) release number.

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

how to collect & write the change log

  • generate a draft changelog with the helper script
  • modify the draft where necessary
  • mention all authors that contributed to this release: 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

Update the default docs version

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)