On Oct 21, 2011, at 6:06 PM, Noah Slater wrote: > On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rnew...@apache.org> wrote: > >> Here's another suggestion. >> >> In all vote emails, we include the commit id that the release >> artifacts were built from, but create no tag at all. >> >> When the release passes the votes, we create the tag, with its final >> name, against that commit id, and push it at the same time we upload >> the artifact to the mirrors. >> >> To obviate any concern about stale 1.1.1 tags in downstream repos, we >> could, for this release only, add a 1.1.1-final tag as an unambiguous >> tag, but only *after* the release is official. >> >> Stated another way; we make each tag exactly once, and refer to the >> build by its commit id until then. Since a commit id in git dictates >> the precise state of the entire tree this is safe. > > > I love it when something is so obvious you wonder why it wasn't apparent in > the first place. I love this suggestion, and the specifics of how you > communicate the git commit hash is unimportant. If there's a "describe" > command to make it easier, so be it. We only tag when we mean to tag a > release, for reals. > > As for the existing Git tags, I don't want to mess things up with a > 1.1.1-final tag. Let's just accept the fact that some downstream > repositories may have stale 1.1.1 tags from the previous two rounds, and go > ahead and delete them. Once the vote passes on 1.1.1, we create a "1.1.1" > tag as per this suggestion and request that people update their downstream > git repos to make up for the fact we've now solidified our release procedure > in a way that means those old tags need to be deleted. Make sense?
`git describe` would read something like 1.1.0-N-deadbeef, where N is the number of commits since the last tag. On .0 releases it would probably just be the commit hash since the commit would not be a descendant of any tags. It's a neat tool but I think it might confuse more than illuminate. I'm ambivalent about using the commit hashes directly. I'd rather use the vote/ or -vote style tags; I don't really share the concerns about cluttering up the tag namespace down the line, and if it does get annoyingly cluttered I'm fine deleting the old vote tags. But it sounds like you find it to be pretty elegant, so I'm happy to go along. Cheers, Adam
