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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to