Release management

People involved in preparing for a release

Table 12 People



Anders Waananen

Packaging, autotools, admin access to Bugzilla and (package downloads

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:

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