couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 21:47:18 GMT
On 21 October 2011 22:20, Dustin Sallings <> wrote:
> 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
>        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

I'm hopefully just summarising what people have said in a non-tech
way, so us simple folk have it clear:

* First and foremost we have to ensure there's no confusion between
the release in the version control system, the named vote tarball(s)
on both people.a.o and the official couchdb.a.o/.... download
tarballs. This saves devs, users and packagers grief.
* Our official releases are the tarball on couchdb.a.o.
* Lots of folk build from git/svn anyway using the tag or branch.
There is an incorrect expectation that these are immutable.
* Namespacing git tags seems like it keeps things tidy and also makes
svn users feel at home.
* Much of the apache release process is around ensuring integrity of
releases. git provides a fair bit of that directly as Dustin's pointed

My 2c;
* Requiring a less-well known git command to sync repos correctly
seems risky. [git --pull --tags]. If that functionality in git does
*not* match the documentation this seems foolish.
* This is a long-lived project. At 3+ releases/year + votes this will
over time get quite long. Some cleaning would be good.

What if we refer to RCs simply by git hash, and then *only* tag the
final agreed release? I know we've got to have the release version
hardcoded (e.g. in GET / and at startup in the erl shell), so this
would need to read the version # already to avoid the release
artefacts needing to be changed post vote. Is this workable?


View raw message