On 21 October 2011 22:20, Dustin Sallings <[email protected]> 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 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 > > > >
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 out. 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? A+ Dave
