On Tue, Jan 12, 2016 at 4:15 PM, Nitin Lamba <[email protected]> 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
