On Sat, Oct 22, 2011 at 1:00 PM, Noah Slater <nsla...@tumbolia.org> wrote: > Jason and Randall, thanks for your dive into the semantic versioning idea. > As you pointed out, CouchDB's use of (as I mentioned previous) the Apple > versioning scheme means that it is indistinguishable from the semantic > versioning concept. However, I don't buy that we need to be shoehorning > "rc1" or "vote1" into the version number so that we can tag it without > conflicting with our actual releases. > > Dustin, thanks for your illuminating response. Some of the things you > describe there sound quite interesting, especially the build related > automation of release details such as version numbers and changelogs. I > guess there might be room for innovation, but that's something I'd like to > look at another time. The Git stuff sounds cool too, though a little beyond > me at this point I will admit. There might be room for improvement in how we > manage our release branches. Perhaps other people, like Paul, want to weigh > in on that? >
Honestly, I stopped caring about 50 emails ago. Next time I cut a release I'll read the CliffsNotes. > My most pressing concern at the moment is that whatever we decide in this > thread should apply to the whole gamut of Apache projects, in broad strokes. > We're actually quite unusual in the fact that we use the GNU Autotools. Most > of the other projects use some crazy Java stuff I don't even understand. But > we can't attempt anything to fancy here, or anything too specific to our > particular set up. > > On Sat, Oct 22, 2011 at 9:53 AM, Robert Newson <rnew...@apache.org> wrote: > >> I'd argue that it is of no interest, after a release, what the release >> artifacts looked like in earlier, failed rounds. We can decide, as a >> community, that there's value in that but I don't see it. If we go >> with reporting the commit id, then you can find them from the mailing >> list archives if you want. >> >> This thread has ranged far and wide but I still think the 'only tag >> the release at the end' policy is clear, simple and preferable to the >> alternatives proposed so far. >> > > I agree. > > >> As for the fact that 1.2 does not descend from 1.1, this is more than >> just a limitation of svn (where a commit can have only one parent). >> 1.1.x and 1.2.x (and releases from either) necessarily diverge and so >> our source repo should reflect that. >> > > It sounds like Dustin has some interesting ideas on how to manage our > back-porting and forward-porting procedures. Managing release branches has > been quite tricky in the past. And if someone with lots of Git-fu wants to > help us manage that process better, I am excited about that. I don't think > this is particularly important for the current discussion though, so is it > best to come back to this later? > > >> Is there a complete alternate proposal to the 'only tag the release at >> the end'? Do we feel we're close to finding one? >> > > I don't think so, and I doubt it. > > >> Finally, it seemed obvious to me that the tag would be signed by the >> same key that the release manager signs the release artifacts with, so >> I was already doing that. I like the idea that the tag should contain >> the tally of votes (including the links to the mail archive). I'll do >> that for 1.1.1 if no one objects. >> > > +1 to the tag being signed by the same GPG key as the release artefacts. > > The mailing list already contains the history of the votes, and the tally of > the final round. It should only be necessary to include a reference to the > final vote tally. The rest can be done by whomever it is following the link. > I don't think it's necessary to include the release announcement or anything > else like that in the tag. Besides, it's important to realise that at the > point the tag is cut, this email hasn't even been sent yet. > > I would suggest something along the following lines: > > - > > Apache CouchDB 1.1.0 was tagged following a successful vote: > > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3CBANLkTinLheqbrD_=zV0i1ShLEyaD8-L=4...@mail.gmail.com%3E >
