[Rock-dev] Proposal: the next Rock release

[Janosch Machowinski]

Hi,
we had an internal discussion on how to release, and came up
with a different strategy :
- Create an (example name) 0714_RC1 Branch from Master of all packets
- If someone does not want his master commits on the release, he/she 
reverts them
  on the RC Branch
- Change all packet sets, to have also branches / Remove this 
in_flavor_stable stuff
- Announce new Release and wait for feedback.
   - Wait for Bugreports
   - Fix the Bugs
   - Announce RC2 ...
- If no hard bugs occur, any more make RCx 0714
Hm, did I forget anything ?
Greetings
      Janosch

Am 17.07.2014 22:21, schrieb 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
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev