Re: Release numbering for branch-2 releases

2013-02-04 Thread Suresh Srinivas
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy a...@hortonworks.com wrote: On Feb 1, 2013, at 2:34 AM, Tom White wrote: Whereas Arun is proposing 2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0 and the casual observer might expect there to be a stable 2.0.1

Re: Release numbering for branch-2 releases

2013-02-04 Thread Stack
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy a...@hortonworks.com wrote: Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a stable release? This way we just have one series (2.0.x) which is not suitable for general consumption. That contains the versioning damage to

Re: Release numbering for branch-2 releases

2013-02-04 Thread Owen O'Malley
I think that using -(alpha,beta) tags on the release versions is a really bad idea. All releases should follow the strictly numeric (Major.Minor.Patch) pattern that we've used for all of the releases except the 2.0.x ones. -- Owen On Mon, Feb 4, 2013 at 11:53 AM, Stack st...@duboce.net wrote:

Re: Release numbering for branch-2 releases

2013-02-04 Thread Suresh Srinivas
On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley omal...@apache.org wrote: I think that using -(alpha,beta) tags on the release versions is a really bad idea. Why? Can you please share some reasons? I actually think alpha and beta and stable/GA are much better way to set the expectation of the

Re: Release numbering for branch-2 releases

2013-02-04 Thread Todd Lipcon
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas sur...@hortonworks.comwrote: Why? Can you please share some reasons? I actually think alpha and beta and stable/GA are much better way to set the expectation of the quality of a release. This has been practiced in software release cycle for a

Re: Release numbering for branch-2 releases

2013-02-04 Thread Steve Loughran
disclaimer, personal opinions only, I just can't be bothered to subscribe with @apache.org right now. On 4 February 2013 14:36, Todd Lipcon t...@cloudera.com wrote: - Quality/completeness: for example, missing docs, buggy UIs, difficult setup/install, etc par for the course. Have you ever

Re: Release numbering for branch-2 releases

2013-02-02 Thread Stack
On Fri, Feb 1, 2013 at 3:03 AM, Tom White t...@cloudera.com wrote: On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: I still have a list of pending API/protocol cleanup in YARN that need to be in before we even attempt supporting compatibility further

Re: Release numbering for branch-2 releases

2013-02-01 Thread Tom White
On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: I still have a list of pending API/protocol cleanup in YARN that need to be in before we even attempt supporting compatibility further down the road. To let others track these it would be useful if they

Re: Release numbering for branch-2 releases

2013-02-01 Thread Andrew Purtell
On Fri, Feb 1, 2013 at 2:34 AM, Tom White t...@cloudera.com wrote: Possibly the reason for Stack's consternation is that this is a Hadoop-specific versioning scheme, rather than a standard one like Semantic Versioning (http://semver.org/) which is more widely understood. If I can offer an

Re: Release numbering for branch-2 releases

2013-01-31 Thread Eli Collins
We also need to spell out what's permissible *before* GA as well. The alpha/beta labels, as I understand them, are not green lights to break anything as long as it's not API compatibility. The API compatibility story has been somewhat fuzzy as well, eg MR2 requires users recompile all their

Re: Release numbering for branch-2 releases

2013-01-31 Thread Arun C Murthy
Stack, On Jan 30, 2013, at 9:25 PM, Stack wrote: I find the above opaque and written in a cryptic language that I might grok if I spent a day or two running over cited issues trying to make some distillation of the esotericia debated therein. If you want feedback from other than the

Re: Release numbering for branch-2 releases

2013-01-30 Thread Vinod Kumar Vavilapalli
I still have a list of pending API/protocol cleanup in YARN that need to be in before we even attempt supporting compatibility further down the road. There's no way we can support wire compatibility with the APIs in the state that they are in now. So, +1 for a beta sometime in March. There are

Re: Release numbering for branch-2 releases

2013-01-30 Thread Arun C Murthy
The discussions in HADOOP-9151 were related to wire-compatibility. I think we all agree that breaking API compatibility is not allowed without deprecating them first in a prior major release - this is something we have followed since hadoop-0.1. I agree we need to spell out what changes we can

Re: Release numbering for branch-2 releases

2013-01-30 Thread Chris Embree
Hi Arun, et. al., I hope you don't mind a non-contributor butting in here. I'm currently a Hadoop administrator and former application developer (non-hadoop). regarding GA release changes, I think Arun has got a lot of good ideas here. I think it's better to add new features via new flags,

Re: Release numbering for branch-2 releases

2013-01-30 Thread Stack
On Tue, Jan 29, 2013 at 12:56 PM, Arun C Murthy a...@hortonworks.com wrote: Folks, There has been some discussions about incompatible changes in the hadoop-2.x.x-alpha releases on HADOOP-9070, HADOOP-9151, HADOOP-9192 and few other jiras. Frankly, I'm surprised about some of them since the

Re: Release numbering for branch-2 releases

2013-01-29 Thread Arun C Murthy
Thanks Suresh. Adding back other *-dev lists. On Jan 29, 2013, at 1:58 PM, Suresh Srinivas wrote: +1 for a release with all the changes that are committed. That way it carries all the important bug fixes. So, rather than debate more, I had a brief chat with Suresh and Todd. Todd