spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <so...@cloudera.com>
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 <jacek@japila.pl> wrote:
> On Sun, Jul 3, 2016 at 3:49 PM, Sean Owen <sowen@cloudera.com> wrote:
>> On Sun, Jul 3, 2016 at 2:42 PM, Jacek Laskowski <jacek@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-unsubscribe@spark.apache.org


Mime
View raw message