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

[yuppie]

Hi!


Jens Vagelpohl wrote:
> On Jun 18, 2008, at 19:27 , yuppie wrote:
>>> 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?
> 
> It's much quicker to look at the change log, and when you work with 
> tarballs there's no subversion history. So no, that's not a good 
> "replacement" for my uses.

Nobody proposes to make releases without a complete CHANGES.txt. In a 
released version you should always find all changes. The only real 
difference between current and proposed policy is how the change notes 
are ordered and grouped.

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.

>>> 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
> 
> 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.


Cheers,

	Yuppie