Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

In the absence of further comments, I've pushed this text to a new "Release
Versioning" page on the website. I think svnpubsub automatically builds and
pushes for us now, but not 100% sure.

Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1
version updates. I'm going to be on vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.

Best,
Andrew

On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I've written up the proposal from my initial reply in a GDoc. I found one
> bug in the rules when working through my example again, and also
> incorporated Akira's correction. Thanks all for the discussion so far!
>
>
> https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> Inline.
>>
>>
>>>
>>>> BTW, I never see we have a clear definition for alpha release. It is
>>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>>> but sometimes means unstable in production quality (2.7.0). I think we
>>>> should clearly define it with major consensus so user won't
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>>    - Early version for testing - integration with downstream, deployment
>>    etc.
>>    - Not feature complete
>>    - No compatibility guarantees yet
>>
>> Beta:
>>
>>    - Feature complete
>>    - API compatibility guaranteed
>>    - Need clear definition for other kinds of compatibility (wire,
>>    client-dependencies, server-dependencies etc.)
>>    - Not ready for production deployments
>>
>> GA
>>
>>    - Ready for production
>>    - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> Also, if we treat our 3.0.0-alpha release work seriously, we should
>>>> also think about trunk's version number issue (bump up to 4.0.0-alpha?) or
>>>> there could be no room for 3.0 incompatible feature/bits soon.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>