Opinion by Sylvain

Summary of requirements

Strong requirements

  • fully reproduceable setup: once we achieve a working system, we definitely want to be able to reproduce it at will, regardless of what happens to Rock itself, or during Rock's development. This includes both public (in rock official package sets) and private packages, as well as the rest of the setup (gems, ...)
  • allow for package development: no system is purely "on release". We always fix bug, have experimental packages, and in general modify 'stable' packages. The project of a maintainer of, say, a motion planner will usually work on the devel version of said software on the project's robots. If we don't account for this, we either assume that released packages are finished and will never be changed again. Or that it is possible for a single developer to reach perfection before putting the software in a robot (and that the project's schedule matches the release schedule).
  • allow for Rock core development: the Rock core developers should be able to easily test the devel version of the core on systems.
  • foster cooperation: one goal of Rock is to be an open project, where people feel free to publish unreleased, unfinished code, allowing others to come and help.

Weaker requirements

  • unsynchronized release process for non-core packages. Rock cannot be released as a whole anymore already. It is a piecewise meal of different packages, and each package (or set of packages) should IMO be seen as a subset that has its own release schedule. There's no point holding onto backward-compatible improvements to an IMU driver just because the next release is 3 months away.

Long version

Having a synchronized release of rock-core and "the rest of Rock" is in my opinion harmful to Rock in the long run:

  • the goal of the non-core part of Rock is to be as rich as possible for robotic applications. Which means that, in the end, it is a collection of completely unrelated packages (for instance KDL and taskmon ...) which are maintained by different people in different places, with different schedules and priorities. Assuming that they can (or should) release all at the same time is a nonsense.
  • the goal of the core part of Rock is to provide a solid foundation on top of which one can build and deploy the rest of the software
  • the Rock core developers cannot support the "whole of Rock". It should be the job of the package maintainers to make sure that their packages are maintained, not the role of the Rock core developers.

In my opinion, ROS is doing it the right way:

  • it provides releases of ROS "core", which is the ROS infrastructure, tooling and some packages that are deemed essential (e.g. PCL). These are frozen within a ROS release so that the package maintainers can do their part, namely
  • package maintainers are the ones deciding when to release their software, for which ROS release (it is common that some packages stay unreleased for the current ROS release for a pretty long time because the maintainers cannot update). In addition, they are free to update their "stable" release within the lifetime of the ROS release.
  • ROS supports the last two stable releases (not only the last one) for this very reason: to give the time for package maintainers to migrate.

In addition, now that we release, we cannot assume that package maintainers will target the last Rock release. They will target the release they are using. I've commonly seen ROS-using labs being 3 or 4 release late, there's no real way to be sure that Rock will be different (apart from hubris).

The flavor implementation is already providing the foundations to migrate to a release system. What is missing:

  • renaming 'stable' to whatever branch or tag the release is using (the release name)
  • a way to generate the overrides to pin the non-rock packages (for which we can't create a release branch or tag). These should IMO also have a Rock "maintainer" who is the one deciding to push updates to Rock. In other words, we should probably make sure that all non-rock packages are *always* pinned to a proper tag or release branch.

The "current release" is the 'stable' flavor, with the addition of pinning non-rock packages (should have been done with the flavor system already). The branching of the package sets can then be done *just before the next release*, and it should be transparent to the release user (i.e. if one requested to be one release X, he/she should not see the transition from "current release" to "one-before-current release"). This will allow package maintainers to request the addition of their package(s) to the release easily (one would simply move the packages to the stable flavor), as well as people to mix-and-match master and current-release system freely (while still being warned about it). We should even pin the master packages to their current commit at the time of the branching (i.e. just before the next release).

This does not solve the bigger issue that there is always custom code on robots. This custom code is never released, and history shows that one cannot assume that robot developers will properly manage branches. Reproducing a "working state" becomes ... challenging. That's what the proposed changes to autoproj should tackle (autoproj auto-snapshotting, tag and commit).

Opinion by Janosch

I see a release of rock more like a Linux distribution. In particular I would keep it similar to the Ubuntu model.


  • A release should be tested as good as possible.
  • A release should not break due to updates.
  • In a release the API is considered stable, including buggy behavior. E.g. Updates to a component, that alter its behavior are considered a regression, even if it fixes a bug.


All of rock should be released together. All packages that go into the release should work together and provide a tested basis for own development.

For additional packages and partly updates, I propose a Ubuntu ppa like approach. Additional package sets, may add further packages, or update packages to newer versions. The ppa packages are not bound to the requirements above.

This matches the new workflow with github, as one needs to clone the packages to work on them. Also on needs to define a custom package set in order to share the work with other people anyway.

The idea here is that the base packages should always work. If one adds a ppa, he knows that he gets unstable code.

All code from the PPAs should go upstream, to become part of the Rock distibution.

In this model, the master branch of packages becomes the integration branch for the next release. An example :
Development is done based on the last release on ones own repo.
If the state is considered stable, he request merge upstream into the rock-xxx repos.
The developer MAY test if the code is working in master.
At the point of release, the developer/maintainer MUST test if the code is working in master.


  • Developers need to add their packages to the standard distribution by merge request, no automatic pickup of packages.
  • If a package is in the rock package set it is considered a part of the rock distribution.
  • All code that is part of the standard rock packages should go into the next release.
  • If a package is unmaintained, or known the be seriously broken, it gets removed from the standard package set.
  • To make life of maintainers easy, a new release picks up master branch code by default, this should be correct in 90% of the cases.
  • A maintainer may downgrade his package while in the release process (rc steps)
  • After start of the RC-Phase every developer should test ones maintained packages.
Last modified 4 years ago Last modified on 03/20/15 10:09:53