Release management

People involved in preparing for a release

Release workflow

  • Decide on release date and timeline on Nordugrid technical coordination weekly meeting - The aim is a monthly scheduled minor release - The timeline contains code-freeze date. From this date on no new merge requests will as a rule be added to master. - Together with the developers a set of minimal tests are defined for the current release in planning. - Clarify if any documenation changes are needed. - The release manager enters the test-descriptions on the GitLab wiki test-page: `https://source.coderefinery.org/nordugrid/arc/wikis/home <https://source.coderefinery.org/nordugrid/arc/wikis/home`_

  • Release manager sends out a heads-up email announcing the release in preparation and its timeline right after the decision of the release is made - to: nordugrid-disucss - Inform that documentation updates should be ready by code-freeze date

  • The day after code-freeze, the agreed test-sites should install the nightly build from the nightly build repository: http://download.nordugrid.org/builds/index.php?pkgname=nordugrid-arc&type=master and report on the tests and any issues encountered - If there are any issues the release date might be postponed.

    • If a postponement is necessary a new timeline is drawn
    • TO-DO: Should a new email go out to nordugrid-discuss or will that just be noise?
    • If no issues are found the release is ready for the next step
  • After the definite code-freeze the translations are run
    • The release manager gives a green light to run translations
    • Translations are run. Responsible: Oxana Smirnova

  • The release manager creates a tag on master - Informs the build-manager about the commit-hash either on skype or by email to nordugrid-core mail list

  • The builds are created and repositories populated. Responsible: Anders Waananen

  • The list of supported platforms is checked for updates. Responsible: Anders Waanaen

  • Once the source tarballs are available in the nordugrid repo, the build in the Fedora build system and for Debian is started. Responsible: Mattias Ellert. - The builds should not be made available before the release is announced. TO-DO: Is this possible?

  • Prepare the release announcement (see more below). Responsible: Maiken Pedersen

  • Notify release manager that the builds are ready to be pushed to the repo. Responsible: Anders Waananen

  • Notify responsible in order to publish the release annoucement on the web. Responsible: Maiken Pedersen - Publish the release announcement. Responsible: Oxana Smirnova

  • Notify responsible in order to push the packages to the nordugrid repo. Responsible: Maiken Pedersen - Push packages to nordugrid repo. Responsible: Anders Waananen

  • Notify responsible in order to push builds to Fedora and Debian repo. Responsible: Maiken Pedersen - Push packages to Fedora and Debian repos. Responsible: Mattias Ellers

  • Ensure there are consistent binary packages in agreed repositories and linked from the release page. Responsible: Maiken Pedersen

  • Ensure there is corresponding release version in Bugzilla. Responsible: Anders Wannanen

The release announcement should contain

  • Most important changes/highlights
  • List of fixed bugs
  • List of new features (if relevant)
  • List of backward incompatible changes (if relevant - only for major releases)
  • Link to documentation in addition to installation links
  • Link to the GitLab ARC repo
  • Getting-in-touch information