Another reason I like the 3.0.0-alphaX approach is the ease of communicating compatibility guarantees.
A lot of our compatibility guarantees (e.g. API/wire compat) mention "within a major release". For the user, thinking of 3.0.0 as the beginning of a major release seems easier than 3.2.0 being the beginning. Most users likely will not be interested in the alphas or betas; I assume downstream projects and early adopters are the primary targets for these pre-GA releases. By capturing what we mean by alpha and beta, we can communicate the compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this applies to both the Hadoop-2 model and the 3.0.0-alphaX model. On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote: > 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 >> > >> > >
