Release management

People involved in preparing for a release

Table 12 People
Name Experties/responsibility
Anders Waananen Packaging, autotools, admin access to Bugzilla and nordugrid.org (package downloads http://download.nordugrid.org/repos/6/)
Balazs Konya Overall coordination
Mattias Ellers packaging and builds, EPEL and Debian uploads (Globus)
Maiken Pedersen Release manager
Oxana Smirnova Bugzilla, Web site, documentation

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
  • 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