incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]
Date Thu, 29 Sep 2016 14:10:44 GMT
On 28 September 2016 at 16:40, Mark Struberg <> wrote:
> But otoh if a project decides to use -RC1..17 it's also fine.
> BUT: they pollute their branches and tags and they actually would need to do a 2nd VOTE
afterwards on the .Final release. So it is much more work and thus not recommended. But otoh
it's not a blocker neither.

They will not need a second vote to retag from say "0.5.0-RC3" to
"0.5.0" - the whole point of a VOTE is to decide if a RC is to going
out as the version it aspires to. It just means you have to use the
"RCx" string only in the tag name and dist directories, not inside the
candidate's <version> strings or filenames.

(Apache projects can also distribute milestone releases - but to avoid
confusion those should not be called "Release Candidates" but rather
'alpha2' etc. and are still formally an "Apache release" with their
own RCs- see )

Projects are not required to do a vote to make a git tag. They are
required to make a vote to publish a release artifact (by policy the
upload to And as you said, the git commit
is (somewhat) cryptographically sound (sha1 has known collisions)  -
so assigning another tag for the commit that was approved (and
referenced) in VOTE is not another release.

One complicating factor is that GitHub will list any tag as a
"Release": See for instance

The tag "apache-import-20150327" was not a release, but is clearly a
good use-case for tagging - in fact I think every SG-imported code
should have such a tag (ideally with --sign).  So a -RC tag will be
listed as a "Release" on GitHub while it's under vote - I can see that
is not good. A workaround would be to use a branch instead - which is
more clearly a moving target.

Perhaps it's possible to enquire with INFRA if there are particular
tags that can be filtered out from the mirroring.

A deleted -RC tag disappears from the main GitHub repository - however
they might appear in forks - not a big deal to me - downstream forks
could also add arbitrary "release" tags in their forks if they so
like. The impact of this varies a bit with the popularity of the
project - something widely known like Groovy is more of risk of having
their Release Candidates sneak into production "out there". (which is
OK as long as they don't call it "Apache Groovy").

I think each project can (and should) decide this - we can list these
pros and cons in the recommendation.

Some projects (incubator and TLP) might have done a VOTE, and then
push out binary and source artifacts to say Maven Central without a
corresponding git tag or source release in dist. This is of course bad
practice - but not what we are talking about here.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message