On Sun, Jul 3, 2016 at 7:03 PM, Jacek Laskowski <ja...@japila.pl> wrote: > 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.
You seem to be accurately describing management of branch-2.0, but we are talking about master. You're implicitly assuming option (a) where nobody is merging changes that are suitable for a future release but not branch-2.0 -- not "and" (b) (they are after all mutually exclusive). I don't think anyone agrees that's acceptable, when we have such an easy solution: branching. --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
