[Rock-dev] Proposal: the next Rock release

[Sylvain Joyeux]

More thoughts ...

On Thu, Jul 17, 2014 at 11:14 PM, Janosch Machowinski
<Janosch.Machowinski at dfki.de> wrote:
> - 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
This is hell. We'll get widely diverging branches or non-fast-forwards
(i.e. people will have to force-push to their branch)

I personally really would like to think separately about rock.core and
rock. The way ROS does is have the 'ros core' managed by the ROS
maintainers, and having the package maintainers in charge of the
non-core parts. This makes sure that the maintainers are aware about
what happens to their packages.

The same way we have the 'stable' tag, I would prefer having an easy
way for the package maintainers to tell "yes, this package can go on
release X" and have an automated mechanism that does so.

> - Change all packet sets, to have also branches / Remove this
> in_flavor_stable stuff
Branching the package sets is problematic (this is why we got the
flavor system as it is right now, we *were* branching before). The
problem is that if a new package gets defined, the user *cannot* get
it.

Again, this should IMO be handled by having a different workflow /
release system for individual packages vs. for rock.core.

> - 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
In order to be more constructive than my previous comment: there
should be a hard deadline between RC cycles (i.e. the "wait for
bugreports step" needs to have a timeout).

Sylvain