On Wed, Oct 19, 2011 at 10:10 PM, Adam Kocoloski <adam.kocolo...@gmail.com> wrote: > On Oct 19, 2011, at 10:53 PM, Dustin Sallings <dus...@spy.net> wrote: > >> >> On Oct 19, 2011, at 6:56 PM, Adam Kocoloski wrote: >> >>> I think you might be reading a bit too much into what Noah is saying here. >>> I believe he's just taking issue with the two separate rc/ and rel/ "paths" >>> in the tag names. For what it's worth I agree with him on that front, >>> though I'd consider going even further (as Paul suggested earlier in the >>> thread) and just prevent rewriting of any tag pushed to the ASF remote. >>> Then there's no need for any tag prefix at all. Best, >> >> >> I don't think that's different from what I said. Tags don't generally >> have "paths" (it's 1.4rc1 or it isn't) and git makes it hard to overwrite >> them because it's a bad idea and will only lead to confusion. >> >> IMO, there just isn't room or need to innovate here. Code's cooked in >> various dev branches. That gets rolled up into an "official" branch towards >> a feature or release. Once a release is almost ready, alpha, beta and RC >> tags get dropped in aligned with the same version numbers the server will >> report. Once it's done, you can retag a commit with a newer tag that calls >> it done and it's shipped. >> >> -- >> dustin sallings > > Git makes it hard, but by no means impossible. The whole reason these > "paths" are even on the table is to add some immutability to the official ASF > repo. A little less convention, a little more configuration. Best, > > Adam
Yes, the "path" prefixes (path probably was a bard word in my original email) exists merely as a way to distinguish between "these are official releases and are immutable" and the "this is a temporary tag that I can fix if I screw up." I'm trying to consider all the cases here (in the context of my OCD). Do we necessarily care about the rc tags once a release has been made? In a perfect world I would expect one tag per release and everything would be neat and tidy. If so, then we need to be able to remove old tags once they have been usurped by actual releases. Consider it from the POV of a user as well. If you have 5-10 tags for a release (not out of the question) then each user looking for that release has to spend time figuring out which is the right tag. Which means that either our naming conventions have to be extremely clear (even then I've seen enough to know that we'll still get questions) or we need to have procedure to narrow down the set of tags once the release is made. I prefer procedure because it will minimize the number of times in the future that i have to spend time debugging the fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that bug related to SpiderMonkey 1.7 and sealing.
