Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 dustin@spy.net does not designate 69.230.8.158 as permitted sender)
From: Dustin Sallings <dustin@spy.net>
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_2AEE5A6B-9C8F-4310-BCF2-66ADFF44ECB7"
Subject: Re: Tweaking the release procedure
Date: Fri, 21 Oct 2011 13:20:35 -0700
In-Reply-To: 
 <CA+Y+446uwLGs8bdLUEwO8Qw9DB62MRKwww3M1PqU84WJE9rOAg@mail.gmail.com>
To: dev@couchdb.apache.org
References: 
 <CAJ_m3YCeLKDMFp3VvB4jsak0GAV8tU59J+Bjks4+Fs8+4c628A@mail.gmail.com>
 <CA+Y+444+pktHo-3g2Y8ieQ=oKbe-oE_BV_UbnnyqYWG0dYMxvg@mail.gmail.com>
 <6BC9C06A-D317-409F-83E8-F898CAB3A617@spy.net>
 <E10FB54E-8362-41DA-A5EA-6876BB5AC605@apache.org>
 <6B64ED84-544F-4C84-9DD4-D794AD025380@spy.net>
 <82F3E1E5-A9C7-4EC7-BEBF-E4BAD753AF85@gmail.com>
 <CAJ_m3YCcSUmD9gGxys2b+SMREUUV3n1iraKQ93Av5dzQOt0FMQ@mail.gmail.com>
 <4FD791CC-15A9-4FE9-97B6-76D1B2BD850C@spy.net>
 <CAJ_m3YAQYQ100OGG3VaKgagMnd47+EjgSjXBiV-UEcQ7ETHrwQ@mail.gmail.com>
 <CAOFYJNYuHjgmrfKRbQao9jEgs7SXcuVYPyTj2EvcJyCQY7HxQw@mail.gmail.com>
 <CAJ_m3YB9JSufjSkb708k2+tdma714pwjmjsAPVAy28sSm03VqQ@mail.gmail.com>
 <AD61DB16-A138-4811-9D84-C9B72932308D@dionne-associates.com>
 <CABvT1DGbKV+CUzZsQoG=+kw0UzpaEr1omOyq0C6Uk3wnj__=0A@mail.gmail.com>
 <166A20A5-399A-4965-ADB9-B4E377D0F41A@spy.net>
 <CA+Y+444-4q=-o_Hof_NP2HWCN+mFPffWg+bqgCF+xhwFrm2bbg@mail.gmail.com>
 <CABvT1DETeRF3DVSyBxYTDZ6G1nOzFqH5F3bvfPmeni4mNf0Gow@mail.gmail.com>
 <2913A185
 -2FDD-498C-B97C-74D44199A258@apache.org>
 <ADA178A9-FB8A-470E-AFB3-62A78B7538A8@apache.org>
 <FD54F72A-59F0-4AFD-A013-44AB29D5D470@apache.org>
 <CA+Y+446uwLGs8bdLUEwO8Qw9DB62MRKwww3M1PqU84WJE9rOAg@mail.gmail.com>
Message-Id: <93C75CB9-F856-4500-B802-D7DCA0796459@spy.net>

--Apple-Mail=_2AEE5A6B-9C8F-4310-BCF2-66ADFF44ECB7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


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.=20

	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.

--=20
dustin sallings


--Apple-Mail=_2AEE5A6B-9C8F-4310-BCF2-66ADFF44ECB7--