hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Shvachko <shv.had...@gmail.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 06:29:17 GMT
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.

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.

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.


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