[Rock-dev] Rock Release 1408

[Sylvain Joyeux]

>> This fails if:
>>   - you want to try a package that did not exist at release time
> Package should be then on a 'additional packages' package set. If you
> want non release packages, you import an extra package set.
So ... Now you want a 'stable' package set and a 'master' package set
? What about packages whose property change between stable and master
(long list already posted ?). We need to duplicate ?

Why change so much when the flavor system already provides a good base
to migrate to a "release frozen in time" system ? You clearly
completely misunderstand how the flavor system works. The stable
flavor *already* provides all the guarantees you are talking about
*until the next stable is pushed*, while still allowing to easily mix
master and stable. Branching the package set "just before the next
release" would then provide release-guarantees for the years to come.

In other words, the heavy patching you've done in the release branches
is really only making the whole release process more complex, and
reducing the usability of Rock for its developers.

>>   - the master branch needs an osdeps that was not declared at release time
>>   - the master branch depends on a package that did not exist at release time
> Agreed, these use cases are rather rough as you need to create a custom
> package set / add it to your project package set.
>>   - the way the package got built changed between the release and now
> This is something we do not want. If the package was build before without
> option X, we want it to stay this way. As enabling option X might change
> the behavior of the package.
What I am talking about is: what if the stable branch of a package and
the master branch of a package need different build options ? This
happened many times before.

>>   - the repository URL changed between the release and now
> The version we are interested in, for the release, should hopefully
> still be at the 'old' url. Actually there were thoughts to mirror external repositories,
> to be sure that we can rebuild anything years later.
Again, I am talking about using the devel version of a released
package while being on a release.

>>   - there are differences in the way the package is patched
> Same as above. Might change runtime behavior.
And same as above, I am talking about using the devel version of a
released package while being on a release. Of course it changes
runtime behaviour, it is what the user *wants*.

There is no "pure user" in Rock (or in ROS for that matter). All
"users" also develop packages, which might or might not be part of the
latest Rock release. Any way to "release" rock will have to cater to
these.

>> 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 remember this. The problem we wanted to solve back then was
> to make it easy to mix the branches, and have only one set of
> osdeps and package definitons. As said above, this does not
> match the use case of the release, as the target is reproducibility.
Of course it does if you branch just before *the next release*.

> All the osdeps need to be frozen to a specific commit / version,
> which is the opposite of how we wanted it in the master/next/stable
> system.
No, it is not. 'stable' was always meant to be fixed until the next
stable release. What we did not bother with is providing a way to go
back to older releases.

Sylvain