On Sep 26, 2007, at 10:10 AM, Martijn Faassen wrote:

Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.
There is conflicting information here. :-) Some people say we need branches, others say we don't.

I think it'd be good to have a tag in any case. A tag can always be converted into a branch later.

Yup. I don't think there is disagreement about tags and we don't really need agreement on branches.

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.

What about using CHANGES.txt, which we should be maintaining anyway?

I agree with a change log. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt.

Before making a release, change CHANGES.txt, and convert the section:


Fixed bugs blah blah.


3.5.1 (2007-09-26)

Fixed bugs blah blah.

That is, come up with a release number, a release date, update setup.py with the release number, and tag it.

Then, after the release, add in a new section:


This way checking CHANGES.txt should tell you what's going on with releases. If someone forgot to do the last step, you see immediately something is wrong, as you want to add your change to the 'unreleased' section but there's nothing there yet. You can then reconstruct what happened from the cheeseshop or the tags, and put in a new 'unreleased' section.

I agree except for the location of the change log.


P.S. ZODB's NEWS.txt/History.txt aren't workable for me and I plan to switch ZODB to using a change log in it's readme. Unfortunately, it's setup is so complex It will take me a largish chunk of time to unwind this.

Jim Fulton
Zope Corporation

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to