More thoughts ... On Thu, Jul 17, 2014 at 11:14 PM, Janosch Machowinski <[email protected]> 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 _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
