This is a check list and notes for v0.3 release. For reference, v0.2 release was done in #46

BAND Framework Release Process

Before release

• A GitHub issue is created with a checklist for the release.

  • This is the issue!

• A release branch should be taken off develop (or develop pulls controlled).

  • See Staging for v0.3.0 #68 and v0.3.0 #93
  • Informed Slack that pulls were being controlled.

• Release notes for this version are added to the CHANGELOG.rst file.

• Ensure that links and references have been updated (e.g., no occurrences of privateband).

• Version number is updated wherever it appears and +dev suffix is removed (in README.md and possibly in CHANGELOG.rst ).

• Check README.md Citing bandframework for correctness (e.g., ensure that author list matches AUTHORS ).

• Tests are run with source to be released (this may iterate):

  1. Online CI (GitHub Actions) tests must pass.

  2. Documentation must build and display correctly wherever hosted.

• Pull request from either the develop or release branch to main requesting
  one or more reviewers (including at least one other administrator).

• Reviewer will check that all tests have passed and will then approve merge.

• Send an email to [email protected] asking to confirm whether the list of email contacts in CODE_OF_CONDUCT.md is up-to-date.

  • Done; all five confirmed they're receiving emails.

During release

An administrator will take the following steps.

• Merge the pull request into main.

• Once CI tests have passed on main:

  1. A GitHub release will be taken from the main

• If the merge was made from a release branch (instead of develop), merge this
  branch into develop.

• Create a new commit on develop that appends +dev to the version number
  (wherever it appears).

After release

• Ensure all relevant GitHub issues are closed.
• Update website to reflect existence of new release.
• Disseminate news of new release to: FRIB-TA mailing list, JETSCAPE/X-SCAPE mailing list, other interested parties.