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