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:
unreleased
----------
Fixed bugs blah blah.
To:
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:
unreleased
----------
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.
Jim
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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
