hadoop-hdfs-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 Wed, 27 Jul 2016 05:34:35 GMT
Thanks for replies Akira and Tsuyoshi, inline:

Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
> Is it right?

Yes, correct.

> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
> Cons:-( A bit redundant.
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport

Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.


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