couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dustin Sallings <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 20:20:35 GMT

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.


		Tagger name, date
		message ("let's vote again on 1.1.1!")
		commit with hash 23c95e52bd01542f803986aa7234980a70d655a4

		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
		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


> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message