As Noah points out, there are ASF procedural issues that affect this discussion. Part of making a release involves getting community input on whether the release is a valid artefact. As such we need to be able to refer to these "not-release" sets of bytes. Traditionally in SVN we did this by creating and delting "tags". Though SVN's idea of tags is pretty bad.
The current issue is how do we create general best-practice guidelines for any ASF project that might be interested in using Git. A naming scheme along with the specific ASF Git hosting code should be considered to try and minimize the confusion across a theoretical couple hundred projects employing a couple thousand committers. > In the above example, if someone downloaded and is currently running > 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and > v1.1.1-rc2, why would be confused? More importantly, you released that, so > why would you not want the user to be able to see whether any changes between > 1.1.1-rc1 and 1.1.1 final affect his deployment? > You're missing my concern. My concern is when someone comes to us and say's, "I'm running 1.1.1" and then I spend a couple hours debugging that they really meant "I'm running 1.1.1-rc1." Anyone that's not scared of this needs to spend more time debugging bugs in community IRC channels or mailing lists. > The git git repo has 366 tags right now. In addition to releases from > a subproject that spun out, there are 337 tags representing releases (and > RCs) that shipped. It captures a wonderful release history of the project. > > These are the tags since (and including) the version I'm running: > > v1.7.4.4 Git 1.7.4.4 > v1.7.4.5 Git 1.7.4.5 > v1.7.5 Git 1.7.5 > v1.7.5-rc0 Git 1.7.5-rc0 > v1.7.5-rc1 Git 1.7.5-rc1 > v1.7.5-rc2 Git 1.7.5-rc2 > v1.7.5-rc3 Git 1.7.5-rc3 > v1.7.5.1 Git 1.7.5.1 > v1.7.5.2 Git 1.7.5.2 > v1.7.5.3 Git 1.7.5.3 > v1.7.5.4 Git 1.7.5.4 > v1.7.6 Git 1.7.6 > v1.7.6-rc0 Git 1.7.6-rc0 > v1.7.6-rc1 Git 1.7.6-rc1 > v1.7.6-rc2 Git 1.7.6-rc2 > v1.7.6-rc3 Git 1.7.6-rc3 > v1.7.6.1 Git 1.7.6.1 > v1.7.7-rc0 Git 1.7.7-rc0 > > I very well may be biased, but I don't find that confusing. > Nor do I, but that is absolutely not the way to think about the issue. Anyone on the dev@ list is pretty much categorically disqualified from making a decision on what's best here. Of course if you follow such a list you'll have an idea on what the "right" release is. But if you're not involved, or even if you're not involved in dev of anything, its not inconceivable (I do know what that word means :) to make the mistake that 1.1.1-rc1 is newer than 1.1.1.
