: > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
