hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hitesh Shah <hit...@apache.org>
Subject Re: [DISCUSS] Release numbering for stable 2.8 and beyond
Date Sun, 26 Apr 2015 16:51:11 GMT
There are a couple of different approaches we could take. 

How about publishing/releasing bits such as “2.8.0-RC0”. Downstream projects can depend
on these and use them normally similar to the approach that they would have taken with release
2.8.0 or 2.8.0-alpha. After some baking ( or more RC suffixed releases), at some point, a
proper 2.8.0 release could be made? The RC tag clearly indicates to downstream layers that
things will be in flux slightly. Trying to distinguish incompatibilities between 2.8.0 and
2.8.1/2.8.2 ( just because 2.8.0 was tagged alpha in documentation ) are likely to be a nightmare
to deal with especially for new features introduced in the 2.8 release ( which might get changed
slightly based on usage feedback ).

Furthermore, considering the release history of hadoop, the likelihood that 2.9.0 will show
up before 2.8.2 seems to be very high.

With respect to the proposed choice (1), I thought that HBase applied a different approach.
The odd-number releases were always unstable and the even number releases were the stable
ones. This “could" make things a bit more clear for downstream users without needing to
resort to modified versioned numbers ( with alpha/beta tags ) or requiring users to go look
up the website to find out which particular version of 2.8.x was the first stable release.

thanks
— Hitesh





On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <vinodkv@hortonworks.com> wrote:

> Forking the thread.
> 
> In the previous 2.7.1 thread [1], there were enough yays to my proposal to wait for a
bug-fix release or two before calling a 2.x release stable. There were some concerns about
the naming.
> 
> We have two options, taking 2.8 as an example
> (1) Release 2.8.0, call it as an alpha in documentation and release notes, wait for a
2.8.1/2.8.2 reasonably stable enough to be called as the first stable release of 2.8.
> (2) Release 2.8.0-alpha, 2.8.0-beta etc before culminating in a 2.8.0 stable release.
> 
> (1) is what I preferred first up. This is what HBase used to do, and far beyond, in the
linux kernel releases. It helps in scenarios where we are forced to downgrade a release, say
due to major issues. We can simply announce it as not stable retroactively, change the pointers
on our website and move on.
> 
> Thoughts?
> 
> Thanks,
> +Vinod
> 
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> 
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <vinodkv@hortonworks.com>
wrote:
> 
>> 
>> Sure, I agree it's better to have clear guidelines and scheme. Let me fork this thread
about that.
>> 
>> Re 2.7.0, I just forgot about the naming initially though I was clear in the discussion/voting.
I so had to end up calling it alpha outside of the release artifact naming.
>> 
>> Thanks
>> +Vinod
>> 
>> On Apr 21, 2015, at 4:26 PM, Andrew Wang <andrew.wang@cloudera.com> wrote:
>> 
>>> I would also like to support Karthik's proposal on the release thread about
>>> version numbering. 2.7.0 being "alpha" is pretty confusing since all of the
>>> other 2.x releases since GA have been stable. I think users would prefer a
>>> version like "2.8.0-alpha1" instead, which is very clear and similar to
>>> what we did for 2.0 and 2.1. Then we release 2.8.0 when we're actually
>>> stable.
>>> 
>>> I don't know if it's retroactively possible to do this for 2.7.0, but it's
>>> something to consider for the next 2.7 alpha or beta or whatever.
>>> 
> 


Mime
View raw message