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

[yuppie]

Jens Vagelpohl wrote:
> 
> On Jun 18, 2008, at 19:00 , yuppie wrote:
>> Why do we maintain a CHANGES.txt file? Who reads it and why?
>>
>> The audience I have in mind are users of released versions. They read 
>> CHANGES.txt to figure out what's new in a release.
>>
>> Let's take Zope 2 as an example:
>>
>> Most people will currently use version 2.10.6. If they read 
>> CHANGES.txt of Zope 2.11.0, they want to know what's new in 2.11.0 
>> compared to 2.10.6. CHANGES.txt of Zope 2.11.0 is 233 lines long and 
>> provides (almost) exactly what they need.
>>
>> You propose to mix in all the change notes made between 2.10.0 and 
>> 2.10.6 with a total of another 240 lines. That makes it almost 
>> impossible to figure out what's new compared to 2.10.6.
>>
>> On the 2.10 branch we have the information which bugfix belongs to 
>> which 2.10 release. You just have to copy that information from the 
>> branch to the trunk. No big burden for the maintainers, but a big win 
>> for the users.
> 
> That's not the only audience. I as a developer consult CHANGES.txt to 
> (hopefully) find *all* changes on the respective branch or on the trunk 
> that have flowed into it until now.

Can't developers use the subversion history?

> I'm not sure what you're saying in that last paragraph. Copying a change 
> history isn't needed when you're diligent about updating the change log 
> whenever you make actual trunk changes.

Sorry. I was referring to the current Zope 2 (and CMF) policy:

"Note that you don't need to note the fix in the CHANGES.txt on the 
trunk if you don't want to. At the time a new feature release is made, 
we merge the items in CHANGES.txt from the trunk and current release 
branch so that for any given release it notes the actual changes as of 
that release." http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess

Cheers, Yuppie