On Sun, Jul 3, 2016 at 3:49 PM, Sean Owen <so...@cloudera.com> wrote: > On Sun, Jul 3, 2016 at 2:42 PM, Jacek Laskowski <ja...@japila.pl> wrote: >> 2. Add new features to master (versions - master: 2.0.0-SNAPSHOT >> branch: 2.0.0-RC1) > > Either: > a) you prohibit anyone from committing anything to master that can't > go into 2.0.0 at this point until it's released, holding up > development, or > b) you allow it and then have a problem below: > >> 4. RC doesn't pass a vote => cut another RC (versions - master: >> 2.0.0-SNAPSHOT branch: 2.0.0-RC2) > > Here, there is no way to create a second release candidate that does > not also have commits in master that weren't intended for 2.0.0
Your "Either" is my "And" :) If a change is on master, it's worth to be released, isn't it? So, when a RC is rejected, master becomes another RC with all the changes in-between. What's wrong with the approach? I can only see benefits. Jacek --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
