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 Tue, 26 Jul 2016 21:03:03 GMT
Thanks Vinod for forking the thread. Let me try and summarize what Allen
and I talked about in the previous thread.

Currently, we've been marking JIRAs with fix versions of both 2.6.x and
2.7.x. IIUC, the chronological ordering between these two lines is actually
not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
entries. This makes sense from a user POV.

The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
Allen's historical perspective is that we've based each minor or major
release off of the previous minor release. So, 2.8.0 would be based off of
2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
be based off of 2.7.0. This also makes sense from a user POV; someone on a
2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
see what's changed.

Having looked at the changelogs of other enterprise software products, this
is pretty standard.

Perhaps restating the obvious, but:

* For a.b.c releases, the "c"s need to be released in order.
* For a.b.0 releases, the "b"s need to be released in order.
* For a.0.0 releases, it comes after a specific x.y.0 release.

Here's an attempt at encoding this policy as a set of rules for setting fix
versions (credit to Allen):

1) Set the fix version for all a.b.c versions, where c > 0.
2) For each major release line, set the lowest a.b.0 version.

The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
a.b.c versions, with alpha1 being the a.b.0 release.

As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
rule 1, and the last two fix versions come from rule 2.

I'm very eager to move this discussion forward, so feel free to reach out
on or off list if I can help with anything.


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