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
* On the trunk, you'll know what release line it is for. Is it 3.4.x? Or
* 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?
These are very good points. My guide  already recommends this practice.
http://worldcookery.com -- Professional Zope documentation and training
Zope3-dev mailing list