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

[Jens Vagelpohl]

On Jun 18, 2008, at 12:09 , Christian Theune wrote:
> - A change on a branch is recorded in the next unreleased section.  
> (Merges of
>  the same fix over multiple branches are not recorded in different  
> places on
>  the other branches.)
>
> This results in the following properties for the CHANGES.txt:
>
> - The trunk will contain sections for feature releases (e.g. 1.0,  
> 1.1, ..) but
>  not bugfix releases (e.g. 1.0.2).
>
> - Bug fixes will appear once in the feature release of the trunk  
> (e.g. 1.1)
>  and once in each individual dot release of the various maintenance  
> branches
>  that it went into (e.g. 1.0.y)

Just for clarification, does this imaginary scenario describe what you  
mean?

  - I am fixing a problem in the 1.2-branch of my Foobar product and  
note the fix in CHANGES.txt on the 1.2-branch

  - I merge the fix to all other currently supported release branches,  
but do not note the fix in CHANGES.txt those branches

  - I merge the fix to the trunk and *do* note it in its CHANGES.txt

So the fix would result in two CHANGES.txt files being updated: On the  
branch where I fixed the problem initially, and on the trunk. On the  
imaginary 1.2-branch, the entry would be in the section for the next  
upcoming sub-release. On the trunk CHANGES.txt, which then only  
carries subsections for each feature (major) release the fix will be  
noted under the next (yet unreleased) feature release version number.

If this is the case I do like the fact that the trunk will always show  
all fixes.

jens