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'

Update the manifest to the package sets that need to be updated, e.g. autoproj/manifest

  - rock.base
  - rock.toolchain
  - rock
  - rock.tutorials

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


In the status messages, the 'remote' is stable and the 'local' is next. If remote has commits that '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 (on next)
  • push it to stable

Run it with


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

Couple of packages are not covers, and need manual treatment, among them:

  • rtt, utilrb, utilmm, typelib, orogen
  • check whether there commits that are in stable, but not in next and if so merge
  • afterwards tag next and push to stable
      * git tag stable-<date>
      * git push --tags
      * git push autobuild next:stable

Third: update the rock package sets, commit the changelog

The rock-release script generates two documentation pages:

  • stable-$ the status BEFORE the synchronization
  • stable-$ the status AFTER the synchronization

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

You can also use rock-tag-diff <stable-from-date> <stable-to-date> It generates the delta between two known tags, and it will fallback to the oldest found stable tag if <stable-from-tag> cannot be found.

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-$ 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 8 years ago Last modified on 01/20/14 08:47:44