wiki:Releasing

This page will describe the workflow about how to release 'next' to the new 'stable' flavor

You need first:

  • to get into a full, uptodate, bootstrap of the next branch
  • to get the admin scripts checked out in this bootstrap: add base/admin_scripts in autoproj/manifest and run aup admin_scripts

First Step: Synchronize 'stable' and 'next'

It is possible that some commits in stable are not yet in next. To verify this, run:

ROCK_FORCE_FLAVOR=stable autoproj status

In the status messages, the 'remote' is stable and the 'local' is next. If remote has commits than 'stable' does not have, you should either:

  • integrate them in 'next' by merging them:
    acd name/of/package
    git pull autobuild stable
    git push autobuild next
    
  • ignore them completely (if, for instance, the changes are bugfixes that do not apply to the current state of 'next')
    acd name/of/package
    git remote update
    git merge -s ours autobuild/stable
    git push autobuild next
    

Do this until there are no commits in 'stable' that are not in 'next'

Second Step: push 'next' to 'stable'

The admin scripts contain the rock-release script that performs the 'push to stable' operations, namely:

  • generate status pages (which will become the changelog entry for this release)
  • tag the current state
  • push it to next

Run it with

rock-release

Note that this script is (mostly) idempotent: you can re-run it until it passes.

Third: update the rock package sets, commit the changelog

The rock-release script generates two documentation pages:

  • stable-$date.page: the status BEFORE the synchronization
  • stable-$date-final.page: the status AFTER the synchronization

Where $date is a date tag for the date in which the release is being made.

With the latter, you get the list of packages that are currently NOT on stable and should be put there. Modify autoproj/remote/rock*/*.autobuild to move the package definitions from the 'master', 'next' sections into the 'master', 'next', 'stable' sections. Commit but do not push yet. First run a complete build.

With the former, you can create the changelog entry. It should be first modified to change the wording (e.g. "are in next but not in stable" becomes "new commits" and so on), compare the existing changelogs with the generated pages to see what should be done there. Moreover, you have to add a title block. See files in the src/changelog subfolder of the Rock website repository for example.

Once the page is modified to fit the "changelog" wording, copy it into the src/changelog/stable-update-$date.page file in the Rock website repository, on all master, next and stable branches (add to stable and merge stable to next, next to master). Push all.

Finally, start a bootstrap on the build server

Final: announce !

Create an announcement message pointing to the changelog page (once the new bootstrap build on the build server is finished, the documentation/website should be generated and therefore the new changelog should appear). See former announcements for examples. The announcement is usually done on the blog as well as on the rock-dev and orocos-users mailing lists.

If there are "highlights", i.e. really important new features, feel free to highlight them there.

Last modified 6 years ago Last modified on 06/19/13 15:31:42