aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <>
Subject Re: [DISCUSS] Tagging development releases
Date Tue, 21 Jan 2014 22:34:23 GMT
(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)

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 <> 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];a=tags
> [2]
> [3]
> [4]
> -=Bill

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message