Re: Release process closure
Philipp von Weitershausen <[email protected]> Wed, 03 Oct 2007 21:44:21 +0200
| Newsgroups | gmane.comp.web.zope.zope3 |
|---|---|
| Message-ID | <[email protected]> |
Jim Fulton wrote: > > I'd really like to get to closure on the current approved release > process. Philipp, would you mind separating the release process into a > separate file? Or do you mind if I do it? Done: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt > WRT version numbers in setup.py. I'm inclined to endorse Philipp's > recommendation for now. If there was a way to specify a version number > on the command line (or in a buildout.cfg) when creating develop eggs, > then I'd have a different position, but given current technology, I > think Philipp's recommendation, as I understand it, is best. Ok. (I should note that I think Tres originally suggested it, but I've been using this practice on a couple of projects, both Zope and private, ever since and it's worked well for me). > I think there are some details missing. I think the intend is that the > version number in the setup.py on the trunk and on release branches > should have the "dev" suffix. I think this is good as a reminder and a > flag that accidentilly released dev eggs are suspect. > > I think the dance should be that, to make a release, you make a tag and > then edit the version number on the tag. I think this sort of editing > on a tag is reasonable and it is fortuitous that svn allows it. I've spelt this out now. Let me know if you think it's still missing something. > Also, by default, the "next" version on the trunk should be a release > with the second number incremented. The next version on a release > branch should have the 3rd number incremented. This is a minor detail, > especially since I think we can avoid release branches for most projects > and I think that release branches shouldn't be created until they are > needed. Of course, tags should always be created. > > There are other improvements that might be made, but let's not let the > perfect be the enemy of the good. Agreed :). -- http://worldcookery.com -- Professional Zope documentation and training