wiki:WikiStart/OngoingWork/RockFlavorsOrReleases

Version 9 (modified by sylvain.joyeux, 6 years ago) (diff)

--

Better releases (opinion by Sylvain)

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).