[Rock-dev] Rock Release 1408

[Sylvain Joyeux]

> I tested the branch for Asguard and Coyote.
> By testing I mean running the robot and
> navigate in the sand field.
That is very impressive. However, it is not what I am discussing. I
*know* that you want releases to be rock-solid (pun not intended), and
I am very grateful that you took so much time testing it. But the
question is about how the releases are going to work, not how
well-tested they are. Ideally, previous Rock release should have been
as well-tested (but were not).

In other words, the issue I have is the way the releases are
implemented, not the fact that we have one.

> The main issue that is solve by this, is that you don't get
> updated, because stable/next/master moved on. Now you
> need to change the release explicitly.
What puzzles me is that you seem to think that the flavor system goes
against having a proper release (at least, that's how I explain how
much you changed the package sets and the name of the wiki page). The
two thing needed to change a stable flavor into a release is:
 - adding a new flavor that inherits stable with the right name. Then
you get the branching right (i.e. autoproj tracks the release name
instead of 'stable')
 - adding the necessary overrides, which is something a little bit of
scripting could do very easily (all the infrastructure is there
because of "autoproj snapshot")

What you do get is:
 - a way for people to tell "package X needs to go in the release"
(they move it to the stable flavor)
 - very little changes between the dev and released system
(package-set-wise), thus avoiding build issues, forgotten packages
that got deleted, this kind of stuff.

> Also I tried to freeze all external dependencies. The only
> ones not being frozen are the ruby ones. Is there a way
> to specify, which versions of the gems get installed ?
Yes, but that's going to be a pain. Enabling it is part of the whole
snapshotting work.

> I don't see why you can't mix devel with release code.
> You just set the override for the branch to whatever
> you want, done.
This fails if:
 - the master branch needs an osdeps that was not declared at release time
 - you want to try a package that did not exist at release time
 - the master branch depends on a package that did not exist at release time
 - the way the package got built changed between the release and now
 - the repository URL changed between the release and now
 - there are differences in the way the package is patched
 - probably other that I don't remember

I've not implemented support for all these in the flavor system just
for fun ... They were all concrete problems that people encountered
(the most problematic one being gui/vizkit that changed from
cmake_package to ruby_package).

I also believe that synchronizing the release of rock-core and the
rest makes no sense, but see

  http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases

Sylvain