spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: [jira] [Resolved] (SPARK-16345) Extract graphx programming guide example snippets from source files instead of hard code them
Date Sun, 03 Jul 2016 18:23:47 GMT
On Sun, Jul 3, 2016 at 7:03 PM, Jacek Laskowski <> wrote:
> On Sun, Jul 3, 2016 at 3:49 PM, Sean Owen <> wrote:
>> On Sun, Jul 3, 2016 at 2:42 PM, Jacek Laskowski <> 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

I don't think anyone agrees that's acceptable, when we have such an
easy solution: branching.

To unsubscribe e-mail:

View raw message