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

[Christian Theune]

Hi,

On Wed, Jun 18, 2008 at 01:11:46PM +0200, Jens Vagelpohl wrote:
> 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

Yes you do. The 1.1 branch would note in its 1.1.x release that the fix was
applied.

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

Yes.

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

Mechanically every branch's CHANGES.txt shows all changes from the perspective
of the particular branch.

When branching off the trunk, you stop recording changes from that branch on
the trunk, so the changelogs of the individual branches will always look like:

TRUNK: Includes changes for the releases 1.0, 1.1, 1.2, and the upcoming
feature release 1.3

Branch 1.2: Includes changes for the release 1.0, 1.1, 1.2, 1.2.1, 1.2.x, ...

Branch 1.1: Includes changes leading to 1.0, 1.1, 1.1.1, 1.1.x, ..., 

Christian

-- 
Christian Theune · ct at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development