hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Thu, 04 Aug 2016 18:20:23 GMT
Hi Konst, thanks for commenting,

On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@gmail.com>

> 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.

> 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.

> 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.


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