I fail to see how "versioning" has anything to do with the "process <http://www.apache.org/foundation/voting.html> [0]" (i.e. voting), and especially, the "tools" (e.g. SVN), used at Apache to push out binary/consumable artifacts used by developers.
*> FWIW, Subversion has a concept of RC's in its versioning scheme - which may be related to how Spring uses it* Most definitely not. All Spring projects <https://github.com/spring-projects> [1] use git/GitHub for SCM anyway. In no way should versioning be dependent on a tool. That includes build tools, such as *Gradle* or *Maven*, even if it meant for convenience with the use of a "release plugin" (1 reason why the "development" version is labeled BUILD-SNAPSHOT and not SNAPSHOT, for instance <https://github.com/spring-projects/spring-data-gemfire/blob/master/gradle.properties#L14> [2]). While there are "semantical" similarities between *Spring's* versioning scheme and the scheme outlined in the referenced document <http://subversion.apache.org/docs/community-guide/releasing.html#release-process> [3], under the section "*Subversion release process*", we certainly do not want the following... "The qualifiers are metadata on the release; we want each subsequent prerelease release to *overwrite* the previous one, and the final release to *overwrite* the last prerelease." All major.minor[.patch] supported *Spring* versions (all the way back to the first milestones and release candidates) are maintained in the *Spring artifact server* (under different repositories, for instance <https://repo.spring.io/list/libs-milestone-local/org/springframework/spring-core/> [4]). I have observed that artifacts can be squashed in *Maven Central*, though I think this is rare. *> If the M1 vote fails, then you move to M2 - you don't reissue a new M1 release.* Why arbitrarily move a version, especially if nothing changes in the codebase/product (that is not visible in the changelog) just because it failed some non-apparent (i.e. to those outside Apache, like users) process (e.g. voting). If it failed because the code did not meet some quality specification, then shouldn't the CI env catch this, and why would a release, and, subsequently, a vote, even commence if the product were not ready in the first place, regardless of version? If it failed for some non-code related reason, perhaps because someone found an error in the releasable artifacts, such as a missing resource/dependency, why would that constitute a new version in order to just seed a new vote. The version "qualifier" has more of a semantical meaning than anything else, that demonstrates the progression towards a quality, production-grade GA release. Not unlike the described SVN process, version qualifiers mean... Milestones (M#, e.g. 1.0.0.M1) - are WIP... feature additions, major enhancements, bug fixes, etc. Release Candidates (RC#, e.g. 1.0.0.RC1) - are the hardening of a particular version prior to final GA... minor enhancements, but primarily bug fixes. Releases (RELEASE, e.g. 1.0.0.RELEASE) - is the final GA, production-grade version, which will be followed by service releases there after until EOL. A typical progression... 1.0.0.M1 1.0.0.M2 1.0.0.RC1 1.0.0.RELEASE 1.1.0.M1 1.0.1.RELEASE 1.1.0.RC1 1.1.0.RC2 1.0.2.RELEASE 1.1.0.RELEASE 1.2.0.M1 1.0.3.RELEASE ... .. . Not sure it needs to be any more complicated than this. $0.02 -John [0] - http://www.apache.org/foundation/voting.html [1] - https://github.com/spring-projects [2] - https://github.com/spring-projects/spring-data-gemfire/blob/master/gradle.properties#L14 [3] - http://subversion.apache.org/docs/community-guide/releasing.html#release-process [4] - https://repo.spring.io/list/libs-milestone-local/org/springframework/spring-core/ On Wed, Jan 13, 2016 at 4:33 AM, Justin Erenkrantz <jus...@erenkrantz.com> wrote: > On Tue, Jan 12, 2016 at 4:15 PM, Nitin Lamba <ni...@ampool.io> wrote: > > Thanks Roman. Seems that ASF may have slightly different convention than > what Spring has been using. Therefore, for the Geode community, we have a > few options to consider: > > > > (a) Use M1, M2..., drop RC# (per Roman) and still have RELEASE suffix > for the final version - each of the milestone and release will have RCs > appended during the voting process. Example: > > > > > 1.0.0-incubating.M1 -> 1.0.0-incubating.M1.RC# (during voting) -> > 1.0.0-incubating.M1 (at release) > > ... > > > 1.0.0-incubating.RELEASE -> 1.0.0-incubating.RELEASE.RC# (during > voting) -> 1.0.0.incubating.RELEASE (at release) > > > > I do see Roman's point of 'RELEASE' tag making it confusing during the > voting process. > > In this scheme, I concur with Roman's followup that you would likely > just drop RC# entirely. The version tag should be stable throughout > the release process. You wouldn't publish the release artifacts into > the distribution channels until after a successful vote. Yet, there > should be no changes after the vote - so, the artifacts should refer > to "1.0.0-incubating-M1", etc, etc. > > If the M1 vote fails, then you move to M2 - you don't reissue a new M1 > release. It still happened, but the community decided not to approve > it for general consumption. > > FWIW, Subversion has a concept of RC's in its versioning scheme - > which may be related to how Spring uses it - perhaps worth taking a > look: > http://subversion.apache.org/docs/community-guide/releasing.html#release-process > > RCs are after beta, but before the next minor rev becomes official and > locked in for API compatibility purposes. The RC release will be > re-issued (removing the "release candidate" descriptor) and re-voted > upon, but all other aspects will be identical. -- justin > -- -John 503-504-8657 john.blum10101 (skype)
