wiki:WikiStart/OngoingWork/RockFlavorsOrReleases/Workflow

Release workflow

Technical details

A "release" is registered in the system by creating a tag in github:rock-core/buildconf. The tag should point to a tree that contains two files:

  • overrides.d/25-release.yml
  • RELEASE_NOTES.md

The first one is the version file. It contains the commit ID/tag/branch/URL/... for all the packages and package sets that are included in the release (i.e. everything that is part of the 'stable' flavor at the point of the release).

The second one contains informations about the release. Apart from the list of changes (the usual changelogs), it also contains deprecation information and ideally some release highlights (a.k.a. "cool stuff")

The versions file is "almost" the file created by autoproj versions. It cannot be created by autoproj versions out of the box because some packages that are included in a release are disabled by default (while autoproj versions creates a snapshot of the current working copy, rock-release must make sure that absolutely all packages that are part of the stable flavor end up versioned properly).

From a user point of view

When bootstrapping, a release can be selected instead of a flavor. This causes the rock.core init.rb script to check out the release's version file in the user's autoproj configuration and restart autoproj.

In an existing rock installation, the rock-release script provides the necessary tooling to play with releases:

rock-release list
rock-release notes RELEASE_NAME

The list of current releases, and a way to read the release notes.

rock-release switch RELEASE_NAME

changes the currently selected release WITHOUT UPDATING. The user can after that call autoproj status, aup --all and/or aup --all --reset. This is explained at the end of the execution.

rock-release pkg-unfreeze PACKAGE

makes PACKAGE (which can be a metapackage) un-frozen, i.e. using the current tip of stable or master instead of the release's version.

rock-release pkg-freeze PACKAGE

freezes PACKAGE back

rock-release set-unfreeze NAME
rock-release set-freeze NAME

equivalent calls for package sets.

How do we create a release ?

The "rock-release admin" subcommand does most of the work. The general process would be:

  1. create a release candidate for all Rock-managed packages and package sets. This creates a rock-rc branch initially initialized from 'stable'. Create what is necessary for rock-release to interpret 'rock-rc' as a valid release version so that people can switch to it. Force-push to the repositories.
rock-release admin create-rc

At that point, package maintainers are free to update the rock-rc branch as well as propose changes to the package sets to migrate packages to the stable flavor. The release manager can send an email announcing the RC with e.g.

rock-release admin announce-rc rock-15.03

Which will send emails explaining what to do about the packages (already released and not-yet released), as well as packages that have no declared maintainers.

Once the RC period is passed, create a proper release locally

rock-release admin prepare rock-15.03

This will tag the current state of all packages with the release name, update the 'stable' branch and create a template for the release notes as well as the version file. As many sanity checks should be added as possible. The release notes must be edited to add relevant non-automatic information (deprecation, cool stuff) before it gets (manually) committed.

The person doing the release should at that point verify that everything builds fine. Once tests are finally integrated, unit tests should also be made to pass.

Finally, create the release tag, push the stable branches to their remote counterparts, and update the package sets.

rock-release admin push

And delete the RC stuff

rock-release admin delete-rc
Last modified 4 years ago Last modified on 03/20/15 13:50:43