Release Cycle

Release Cycle

Start a new release cycle

• Have a look at the Roadmap and decide on a version number.
• Create a milestone on the issue tracker https://github.com/tpaviot/oce/issues/new
• Create a meta issue for this version and set its milestone. Have a look at https://github.com/tpaviot/oce/issues/10 for an example. This meta issue must not be closed before this version is released, otherwise milestone is automatically closed and cannot be reopened.

During development

• Update the Roadmap
• Check that all issues targeted to this milestone are fixed
• Stop development at least one week before the due date to focus on fixing bugs
• Fix version numbers at the top of CMakeLists.txt
• Tag release candidates and ask on oce-dev for tests

Release

• Update the NEWS file. For instance, run git log --name-status --reverse OCE-0.3.0..HEAD to display commits merged since 0.3.0 has been released
• Check version numbers in CMakeLists.txt: OCE_VERSION_DEVEL must be empty, and OCE_ABI_SOVERSION must have been bumped if there are incompatible changes since the last official release
• Add the final tag, and push it with git push --tags origin; in order to check that no other changes are pushed, run git push --dry-run --tags origin first
• Edit the Download page and update direct links to sources
• Send an email to the oce-dev mailing list
• Remove tag for release candidates, they are not very useful; deleting remote tags is not straightforward with git (because most people think that this should not be allowed), one can run for instance git push github :refs/tags/OCE-0.3.0-rc1
  To avoid problems it may be appropriate to delete the local tag too, with git tag -d OCE-0.3.0-rc1
• Close the meta issue; normally all other issues affected on this milestone have already been closed, so this is the last one and this milestone is automatically closed. It cannot be reopened.
• Bump version number to the next development version at the top of CMakeLists.txt