[Zope3-dev] Re: Release process closure

Philipp von Weitershausen philipp at weitershausen.de
Wed Oct 3 15:44:21 EDT 2007


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


More information about the Zope3-dev mailing list