Approach (1) seems like a good way to handle stability concerns people might have. If we explicitly distinguish between current and stable (i.e., not set them both to the latest release). It would be nice to do a VOTE for calling a release stable.
I would use approach (2) for compatibility concerns. Ideally, I wouldn't ship anything in a release unless we are sure we can preserve its compatibility. If we really think a feature is not ready, we could always guard them with private configs that devs or beta-testers could enable to use. In the past, there have been proposals about labeling specific features alpha and beta. I am open to considering it provided we define what those terms mean, ideally in our compat guidelines. On Wed, Apr 22, 2015 at 2:46 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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. > > >> > > > > > -- Karthik Kambatla Software Engineer, Cloudera Inc. -------------------------------------------- http://five.sentenc.es
