[Zope-dev] Re: Extend specification of how to maintain the changelog

[yuppie]

Jens Vagelpohl wrote:
> 
> On Jun 19, 2008, at 13:36 , yuppie wrote:
> 
>> Jens Vagelpohl wrote:
>>> On Jun 19, 2008, at 12:32 , yuppie wrote:
>>>> There is always *one* well defined current maintenance branch. 
>>>> Version numbering *does* imply a time line if you ignore old 
>>>> maintenance branches. It's not hard at all to get this right.
>>> I don't think that assumption holds true. Again, using the CMF as an 
>>> example, there were times when we had 3 release branches. I don't 
>>> want to start a discussion why that was or how to prevent that from 
>>> happening, I'm just saying it's not correct to say you always have 
>>> just one maintenance branch. And that's where all those fancy schemes 
>>> fall down.
>>
>> You did get me wrong :(
>>
>> I tried to make a distinction between the current maintenance branch 
>> (= branch for maintaining the *current* release) and old maintenance 
>> branches (= branches for maintaining older release). If someone knows 
>> better terms, please let me know.
>>
>> The *current* version of CMF is 2.1.1. If you release CMF 1.6.5 with 
>> some backports from the 2.1 branch, it will not become the *current* 
>> CMF release. As soon as CMF 2.2.0 is released it will become the 
>> current release and the 2.2 branch the current maintenance branch. No?
> 
> Sorry, you're right, I realized I did get you wrong after sending my 
> reply. As always ;-)
> 
> I do have one last question, though (unless I misunderstand something, 
> again): In my understanding, we're now down to a single policy 
> difference, about the point in time when you want the trunk CHANGES file 
> updated. You're still saying it will only ever be fully updated when the 
> current release branch changes are merged in, probably just before 
> creating a new release branch, right?

And you did get me wrong again ;)

My first mail today started with these sentences:
> Second try. My first response to this lead to a discussion about immediate or delayed syncing of CHANGES.txt. That was not my point.

I'm fine with keeping CHANGES.txt on the trunk always up to date.


The policy difference I'd like to discuss is something completely 
different: How are the change notes grouped on the trunk?

The proposed new policy is to put everything in one big section: 
Forward-ports from the current maintenance branch and "trunk only" 
changes are mixed together. CHANGES.txt just shows the difference 
between pre-releases of major versions.

The old policy, which I like better in this point, solves this 
differently: Change notes for forward-ports are grouped by release 
versions from the current maintenance branch. CHANGES.txt helps you to 
figure out differences between any two versions in the series of 
'current' versions, not only between major versions.

Note that the policies are the same for CHANGES.txt files on all 
branches. They are only different for CHANGES.txt on the trunk.

Cheers, Yuppie