lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: managing CHANGES.txt?
Date Thu, 09 Jun 2011 20:44:43 GMT

: > The approach (and the cleanness of the merges) completley breaks down if
: > you start out assuming a feature is targetting 4x, and then later decide
: > to backport it.
: you just first move your change to the 3.x section?

so you're saying that to backport something from trunk to 3x you're 
saying the process should be:
 * first you should commit a change to trunk's CHANGES.txt moving the 
previously commited entry to the appropraite 3.x.y section
 * then you should merge the *two* commits to the 3x branch


that seems like kind of a pain in the ass considering it still doesn't 
track reality: the change really was commited to two completly distinct 
branches of development -- the underlying code changes made to 
implement a feature/fix might be radically differnet -- both should be 

: we already raised this issue and decided against it for a number of
: reasons, it was raised on the dev list and everyone voted +1

i contest your characterization of "everyone" but clearly i missed that 
thread back when it happened.  That only address the issue of 3.x feature 
releases after 4.0 comes out -- but it still doesn't address the porblem 
of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a 
serious problem if we keep removing things from the trunk CHANGES.txt when 

As i've said before...

> Arguably we could dedup identical entries so that each entry appears 
> only once (i suggested this before and now think i was wrong), but that 
> loses information: people who see that LUCENE-9876 was fixed in 2.9.4 
> have no context of wether that fix was in 3.0.2 or 3.0.3 -- to have that 
> full context it makes sense for each "fix" commited in a branch to 
> actually be listed in the first release on that branch that the fix was 
> in.  

If 4.1 comes out, and then i commit a bug fix to trunk which gets 
backported to the 3_7 branch and included in a 3.7.1 release it should 
*still* be in the trunk CHANGES.txt for inclusion in the 4.2 CHANGES.txt.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message