On 28 September 2016 at 16:40, Mark Struberg <strub...@yahoo.de.invalid> 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 https://www.apache.org/dev/release.html#release-types ) 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 http://www.apache.org/dist). 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 https://github.com/apache/incubator-commonsrdf/releases 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
