hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Tue, 09 Aug 2016 13:20:32 GMT
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 <kasha@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 <jdu@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 <kasha@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@hadoop.apache.org; mapreduce-dev@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.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <andrew.wang@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@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
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message