You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aurora.apache.org by Bill Farner <wf...@apache.org> on 2014/01/21 22:55:35 UTC
[DISCUSS] Tagging development releases
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
Re: [DISCUSS] Tagging development releases
Posted by Kevin Sweeney <ks...@twitter.com>.
+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 <wf...@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
>
--
Kevin Sweeney
@kts
Re: [DISCUSS] Tagging development releases
Posted by Kevin Sweeney <ke...@apache.org>.
(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 <wf...@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
>
Re: [DISCUSS] Tagging development releases
Posted by Jake Farrell <jf...@apache.org>.
As long as we are not emailing out to any other lists or distributing the
tagged versions then this is not an issue as the tags are not considered
releases, they are test packages [1]. Since these are test packages they
can have any version number they want.
Since this is a Twitter specific we should work to get this changed before
the first release. I would say we have a discussion when we are getting
ready for the first release candidate and we decide on the projects
starting version number and remove all the existing tags at that point.
An example of tagging in use from other TLP projects all only tag release
candidates and then the official releases [ Cloudstack, Cassandra, Couchdb,
Maven, Thrift, Mesos ]. PEP-440 [2], DVCS based version labels states that
".devN suffix may be used to uniquely identify such releases for
publication", since these are test packages [1] from trunk and are not
releases or release candidates which will be published I would propose we
use the following format:
Builds from trunk (no git tag needed): aurora-0.x.x-incubating-dev-{git
short sha}
For the release candidate (tag created): aurora-0.x.x-incubating-rc#
For the release (tag created): aurora-0.x.x-incubating
-Jake
[1]: http://www.apache.org/dev/release.html
[2]: http://www.python.org/dev/peps/pep-0440/#id22
On Wed, Jan 22, 2014 at 2:16 PM, Bill Farner <wf...@apache.org> wrote:
> I'll assume silence is agreement here, and will hopefully be creating one
> of these tags today.
>
> -=Bill
>
>
> On Tue, Jan 21, 2014 at 1:55 PM, Bill Farner <wf...@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
> >
>
Re: [DISCUSS] Tagging development releases
Posted by Dave Lester <da...@berkeley.edu>.
+1
On Wed, Jan 22, 2014 at 11:16 AM, Bill Farner <wf...@apache.org> wrote:
> I'll assume silence is agreement here, and will hopefully be creating one
> of these tags today.
>
> -=Bill
>
>
> On Tue, Jan 21, 2014 at 1:55 PM, Bill Farner <wf...@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
> >
>
Re: [DISCUSS] Tagging development releases
Posted by Bill Farner <wf...@apache.org>.
I'll assume silence is agreement here, and will hopefully be creating one
of these tags today.
-=Bill
On Tue, Jan 21, 2014 at 1:55 PM, Bill Farner <wf...@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
>