Re: faulty releases and pypi access [update]

Martijn Faassen wrote:
>> And where is an agreed-upon document that you have to list the next 
>> version in the setup.py file after the release? Because I disagree 
>> with that, since you cannot know the next version.
> 
> I disagree with too, for the same reason.

I'm not saying you should foresee the future, but I think you can very 
well know the next *anticipated* version. Doing so has some benefits:

* We need *a* convention, otherwise people will either release an egg 
with the same version twice (this happened to Jim with the ZODB 
yesterday, due to the lack of a convention) or skip a release number 
because they both increment after and before a release (happened to 
Roger yesterday; it's harmless but confusing).

* It is a convention that setuptools encourages (third para in 
http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-releases-using-subversion)

* On the trunk, you'll know what release line it is for. Is it 3.4.x? Or 
3.5.x?

* Even more important, when the trunk was used for 3.4.x and now you 
want to add a feature and want to bump it to 3.5.x, you explicitly see 
this in setup.py. And then you know that you have to create a 3.4 branch 
before you do this.


> What about using CHANGES.txt, which we should be maintaining anyway?
> [snip]

These are very good points. My guide [1] already recommends this practice.

[1] 
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt


-- 
http://worldcookery.com -- Professional Zope documentation and training