Release procedure


The following notations are used on this page.

  • X.Y.Z stands for the new release.

  • A.B.C stands for the previous release.

Any release

  1. Determine what version number should be released according to Semantic Versioning. Major version should be changed whenever an incompatible change occurs on the CLI or the protocol.

  2. Update the Changelog. All modifications since last release that may impact users should be given. git diff vA.B.C [--stat] can be helpful here.

  3. Bump version wherever needed. git grep 'A.B.C' can be helpful here.

  4. Tag new version with annotations: git tag -a vX.Y.Z. Put the changelog of the new release in the long description.

  5. Push the tag on the Continuous Integration ‘s repo and make sure it passes. Pushing a tag can be done via git push REMOTE vX.Y.Z. If the tag is not validated by Continuous Integration, delete the tag (git tag --delete vX.Y.Z && git push --delete REMOTE vX.Y.Z), fix the issue and start again.

  6. Push the tag on all remotes.

Main release (not for pre-releases)

  1. Do all steps of Any release.

  2. Update the releases branch. Do not resolve the merge as a fast-forward! This should be done via git checkout releases && git merge --no-ff vX.Y.Z. The goal is that the releases branch only contains released versions (git log --first-parent --oneline releases).

  3. Push the releases branch on all remotes (git push REMOTE releases).

  4. Create a new Batsim package in kapack.

    • The package name should follow Nix standard nomenclature (nix-env -f -i batsim-X.Y.Z).

    • The default batsim should point to the new package (nix-env -f -iA batsim).

    • The previous Batsim package should remain accessible (nix-env -f -i batsim-A.B.C).