hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Fri, 05 Aug 2016 00:19:59 GMT
> 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.

Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.

Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>

Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.

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

We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C

To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

View raw message