Martijn Faassen wrote:
And where is an agreed-upon document that you have to list the next version in the 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 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 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 [1] already recommends this practice.


-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to