lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
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 
tracked.

: 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
: 
: http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810

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

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.


-Hoss

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message