Thanks for forking this Vinod, Linux used to do the odd/even minor versions for unstable/stable, but that went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just always stable. The odd/even though was at least a convention everyone knew about.
Stack can comment better than I about HBase versioning, but my impression is that they do something similar. Evens are stable, odds are not. I'd be okay with an even/odd convention, but it would still be our third versioning convention in as many years. I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract since 2.2 has been that everything is compatible / stable. Adding a tag makes it very clear that we are now doing unstable releases. This also has the pleasing property that we culminate in a 2.x.0, rather than stable starting at 2.x.4 or whatever. Much simpler than having to consult a website. Re (2), we should add a number (e.g. alpha2) too in case there's more than one alpha or beta too. Best, Andrew On Wed, Apr 22, 2015 at 2:17 PM, Vinod Kumar Vavilapalli < vino...@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 < > vino...@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.w...@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. > >> > >
