On Oct 21, 2011, at 12:57 PM, Noah Slater wrote:
> It sounds trivial, but I think it's important to namespace these instead of
> using suffixes.
The only practical difference is the grep you use when looking for
stuff, IMO. I think it will be unambiguous, but a bit less consistent with
other uses of tags in git projects. At one point, there was a bug in some git
commands involving tags with slashes in the name (akin to spaces in filenames
kinds of bugs). I'm pretty sure they've all been fixed.
The de-facto standard (i.e. the thing people would be looking for) is
to prefix release tags with a "v". e.g. "v1.1.1"
> We'd then copy this to the "release/1.1.1" tag in Git once the vote passed.
I don't quite understand this language. Tags aren't copied, they're
just created. You can have as many tags as you want pointing to the same
location.
> The ASF suggests (as does Jukka in this thread) that nothing be required of
> the source code once the vote passes.
Does this just mean you don't want to have the tree self-identify based
on the latest tag pointing to it? Unlike subversion, the *exact* code is used
when accessing a tag.
Example:
vote-1.1.1-3
Tagger name, date
message ("let's vote again on 1.1.1!")
commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
v1.1.1
Tagger name, date
message ("CouchDB 1.1.1 Release\n[lots of release notes]")
commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
Author name, date
Committer name, date
Description
Parent pointer(s)
tree with hash bc4e6b426f8004a0e0b486f6c5ea610bb2026688
It's cryptographically provable that nothing changes between those two
tags (though I'd definitely write up a fresh set of release notes to store
within that new tag).
> vote/1.2.2/2
> vote/1.2.2/3
> release/1.1.1
> release/1.2.0
vs.
> 1.2.1-vote2
> 1.2.2
> 1.2.2-vote1
> 1.2.2-vote2
> I think there is a much clearer separation of concerns in the first example.
It looks like you're mostly concerned about the default sorting order
of the full tag list command. I don't think it's a huge deal either way.
I'm around +0.9 on this since ambiguity goes away, but still seems that
doing a more "standard" release tag is good idea since that's the most clear.
--
dustin sallings
