[Rock-dev] Proposal: the next Rock release

[Sylvain Joyeux]

After the (long) discussion about changing the Rock release strategy,
I would like to propose the following workplan:

1. (Jakob) implement autoproj commit and autoproj tag
2. (?) implement the overrides.d folder, and make sure that we can
override the package sets there (it is currently not possible)
3. (?) release a new version of autoproj
4. (?) create a new tool (rock-update ?) which replaces the current
flavor selection
    rock-update devel
       deletes overrides.d/00-stable-VERSION.yml and/or
overrides.d/00-stable-rolling.yml, runs aup --all
    rock-update rolling
       deletes overrides.d/00-stable-VERSION.yml, adds
overrides.d/00-stable-rolling.yml which sets all branches to 'stable',
runs aup --all
    rock-update latest
       updates the overrides file to the latest stable (from the head
of the 'stable' branch) and runs aup --all
    rock-update changes
        allows to inspect the difference between the current stable
and the latest stable. We should probably simply open a browser to the
website (which contains that information already).
    rock-update VERSION
       updates the override file from the given tag and runs aup --all

When I say 'stable' branch and VERSION tag, the tool accesses the
(authoritative) rock-core/buildconf.git repository, NOT the user's
repository. This is about rock (actually, rock.core), not the complete
installation.

5. (?) Make the current master the new stable *AND* freeze
    -> New bootstraps would have a frozen rock.core
    -> the autobuild files will run the rock-update tool based on the
current flavor (i.e. rock-update latest if 'next' or 'stable' and
rock-update master otherwise).

ISSUES
 - the current snapshotting mechanism does NOT deal with the fact that
gems change. Which means that a working installation can be broken
when reproduced because a gem version changed in an incompatible way.
The best way to fix this would for me be to look into bundler as a way
to install the gems (instead of pure rubygems) and put bundler's
Gemfile.lock in the snapshots.
 - this is going to take some time. Given that rock.core has really
not changed much the last months, maybe we should release the current
'master' as 'stable' right away and follow this plan for the next
release.

Sylvain