Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am not aware of any other software shipped that way. While being used by other software does not make an approach right, I think we should adopt an approach that is easy for our users to understand.
The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been proposed and okay for a long while. Do people still consider it okay? Is there a specific need to consider alternatives? On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <j...@hortonworks.com> wrote: > I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is > something less confusing than incompatible between 2.8/2.9 and 2.98.x > alphas/2.99.x betas. > Why not just follow our previous practice in the beginning of branch-2? we > can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our > APIs, we should bump up trunk version to 4.x for landing new incompatible > changes. > > Thanks, > > Junping > ________________________________________ > From: Karthik Kambatla <ka...@cloudera.com> > Sent: Monday, August 08, 2016 6:54 PM > Cc: common-...@hadoop.apache.org; yarn-...@hadoop.apache.org; > hdfs-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org > Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) > releases [Was Setting JIRA fix versions for 3.0.0 releases] > > I like the 3.0.0-alphaX approach primarily for simpler understanding of > compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing > because, it is not immediately clear that 3.0.0 and 3.1.0 could be > incompatible in APIs. > > I am open to something like 2.98.x for alphas and 2.99.x for betas leading > to a 3.0.0 GA. I have seen other projects use this without causing much > confusion. > > On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.had...@gmail.com> > wrote: > > > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <andrew.w...@cloudera.com> > > wrote: > > > > > Hi Konst, thanks for commenting, > > > > > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko < > > shv.had...@gmail.com > > > > wrote: > > > > > >> 1. I probably missed something but I didn't get it how "alpha"s made > > >> their way into release numbers again. This was discussed on several > > >> occasions and I thought the common perception was to use just three > > level > > >> numbers for release versioning and avoid branding them. > > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. > What > > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to > > >> 3.1.0 would be perfectly in line with our current release practices. > > >> > > > > > > We discussed release numbering a while ago when discussing the release > > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a > > > fourth level as you say, but the intent is to only use it (and > "-betaX") > > in > > > the leadup to 3.0.0. > > > > > > The goal here is clarity for end users, since most other enterprise > > > software uses a a.0.0 version to denote the GA of a new major version. > > Same > > > for a.b.0 for a new minor version, though we haven't talked about that > > yet. > > > The alphaX and betaX scheme also shares similarity to release > versioning > > of > > > other enterprise software. > > > > > > > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think > it > > went well with user perception. > > Say release 2.0.5-alpha turned out to be quite good even though still > > branded "alpha", while 2.2 was not and not branded. > > We should move a release to stable, when people ran it and agree it is GA > > worthy. Otherwise you never know. > > > > > > > > > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0. > > >> The release number is not intended to reflect historical release > > >> sequence, but rather the point in the source tree, which it was > branched > > >> off. So one can release 2.8, 2.9, etc. after or before 3.0. > > >> > > > > > > As described earlier in this thread, the issue here is setting the fix > > > versions such that the changelog is a useful diff from a previous > > version, > > > and also clear about what changes are present in each branch. If we do > > not > > > order a specific 2.x before 3.0, then we don't know what 2.x to diff > > from. > > > > > > > So the problem is in determining the latest commit, which was not present > > in the last release, when the last release bears higher number than the > one > > being released. > > Interesting problem. Don't have a strong opinion on that. I guess it's OK > > to have overlapping in changelogs. > > As long as we keep following the rule that commits should be made to > trunk > > first and them propagated to lower branches until the target branch is > > reached. > > > > > > > > > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may > > >> think of another rule that if a release branch is not released in 3 > > month > > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is > > too > > >> much work syncing it with branch-2. > > >> > > >> Time-based rules are tough here. I'd prefer we continue to leave this > up > > > to release managers. If you think we should recut branch-2.8, recommend > > > pinging Vinod and discussing on a new thread. > > > > > > > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM) > > can recut from the desired point. > > People were committing to branch-2 and branch-2.8 for months. And they > are > > out of sync anyways. So what's the point of the extra commit. > > Probably still a different thread. > > > > Thanks, > > --Konst > > >
