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

[Jens Vagelpohl]

On Jun 18, 2008, at 20:30 , yuppie wrote:
> The current Zope 2 policy doesn't make sure the change history of  
> unreleased versions is complete. But that's no essential part of  
> that policy. And working with unreleased versions you might use  
> subversion anyway.

See, I think that's bad. The change log should reflect all changes, be  
it in a released version or from Subversion. Or be it a release branch  
or the trunk.


>>> "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
>> I think I have done some of that merging once in a while, but  
>> always in a haphazard fashion and did not know about the URL you  
>> provided. I personally dislike that, and would strongly favor  
>> noting every change on the trunk as it is checked in, just like you  
>> would do on the branch.
>
> Well. I don't like the "if you don't want to" part of the current  
> policy because it just creates chaos. If everybody follows the same  
> policy, the merging is not that much work.

It is much work if you have more than a single release branch. With  
the CMF, we have had times recently where stuff is updated on up to 3  
branches plus trunk. Having to consult all those branches to  
synthesize the change log on the trunk is a major PITA and I don't see  
how that can be sane.

jens