aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <>
Subject [DISCUSS] Tagging development releases
Date Tue, 21 Jan 2014 21:55:35 GMT
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



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