Re: Re: faulty releases and pypi access [update]

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