(Repost from my apache address since reply #1 likely got sent to spam) +1. I think it's useful to be able to mark development snapshots that can be understood by package managers as distinct incrementing versions for pre-RC integration testing/performance testing/early adopter deployment. Creating a dev tag is not a statement of any particular fitness for release, just a tool used by a committer to do some integration testing. In some sense it's just a mapping from a git sha to an incrementing number understandable by package managers that leads to reproducible builds. In this proposed scheme the contents of .auroraversion look like this:
0.4.0-snapshot # The master branch always has a -snapshot suffix | |\....0.4.0-dev2014012101 # First dev snapshot of a day created to do some integration testing | |\....0.4.0-dev2014012102 # Second dev snapshot of the day (unlikely but sometimes necessary) | |\....0.4.0-rc1 # A release candidate, announced to the list for a VOTE (artifacts published to the mirrors) | |\....0.4.0 # The official VOTEd 0.4.0 release (artifacts published to the mirrors) | 0.5.0-snapshot This model allows for reproducible builds. For example if I have a development snapshot tag I can recreate all its artifacts: git fetch --tags git checkout 0.4.0-dev2014012101 # ./gradlew distTar or ./pants py or ./pants setup_py ... And the same is true for releases: git fetch --tags git checkout 0.4.0 # ./gradlew distTar or ./pants py or ./pants setup_py ... Another benefit is that all tags are terminal and can be removed after some period of time (say 3 months for development snapshots). They also won't pollute the development history (git log on master or from a release tag won't show them). On Tue, Jan 21, 2014 at 1:55 PM, Bill Farner <wfar...@apache.org> wrote: > Hi folks, > > So far, we've been tagging commits [1] that match builds that have been > deployed in production, following semver [2] semantics: However, this > approach has been sidestepping the Apache release vote protocol (VOTE > threads). This means that we will *probably* have to delete these tags at > some point, and revert our version number to its state at initial Apache > import. (*Jake*: please correct me if i'm wrong on that.) > > These tags are effectively leaking Twitter's deploy schedule. While this > is not an issue for Twitter, the approach is Twitter-specific, and we > should change to something that accommodates other installations. Our > first thought was to move our tagging to a private repository, but Kevin > pointed out that having tags reflecting known-stable SHAs (until we have > formal releases) is useful. With that in mind, i propose that we continue > this tagging practice until our first release, with a minor modification. > Semver supports our situation in a way that Jake tells me can be > compatible with Apache protocols: > > *A pre-release version MAY be denoted by appending a hyphen and a series of > > dot separated identifiers immediately following the patch version*. > > Identifiers MUST comprise only ASCII alphanumerics and hyphen > [0-9A-Za-z-]. > > Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include > leading > > zeroes. Pre-release versions have a lower precedence than the associated > > normal version. A pre-release version indicates that the version is > > unstable and might not satisfy the intended compatibility requirements as > > denoted by its associated normal version. *Examples: 1.0.0-alpha, > > 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92*. > > > (emphasis mine) > > Kevin's proposed tagging format is: > > $VER-devYYYMMDDRR (where RR is "%.2d" % num_releases_today) > > dev is proposed instead of snapshot because it matches PEP-440 [3] and is > compatible with maven version number rules [4]. > > I'm interested in thougs people have on this. Please keep in mind that > this is provisional, and to be halted or re-evaluated after our first > release. > > [1] https://git-wip-us.apache.org/repos/asf?p=incubator-aurora.git;a=tags > [2] http://semver.org > [3] http://www.python.org/dev/peps/pep-0440/#developmental-releases > [4] http://mojo.codehaus.org/versions-maven-plugin/version-rules.html > > > -=Bill >
