> 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: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
