hadoop-mapreduce-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 22:37:16 GMT
On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cdouglas@apache.org> wrote:

> I agree with Konst. The virtues of branching (instead of releasing
> from trunk) and using the version suffix for the 3.x releases are lost
> on me. Both introduce opportunities for error, in commits, in
> consistent JIRA tagging, in packaging...
> I'm certainly open to alternate proposals for versioning and fix versions,
but to reiterate, I like this versioning since it imitates other enterprise
software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.

I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.


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