Someone mentioned the 3.x section of trunk's CHANGES.txt file on IRC a while back, and i forgot to follow up on mail about what/why that was there -- i had never noticed it before.
: Instead of maintaining two places to edit, why don't we just have trunk : track only those things that are exclusive to trunk? Anything that is : committed to both goes in the X.Y version (i.e. 3.x). Then, when it is : released, we can just copy it over to trunk. That has the downside of I mostly agree with Grant, but i think it should be even simpler: if you commit something to a "branch" (using the term loosely, "trunk" is branch), add it to the CHANGES.txt for the next target version on that branch. People commiting bug fixes to the 3x branch (that don't affect trunk) shouldn't have to worry about adding to two differnet copies of CHANGES.txt People committing to multiple branches shouldn't have to worry about only commiting to the "lowest branch numbers" copy of CHANGES.txt -- backporting a patch from trunk to branch_3x might be done by two differnet people many weeks apart. that backport shouldn't involve removing something already in trunk's changes. Anytime 3.whatever is released off the 3x branch, we can bulk copy it's CHANGES.txt entries over to trunk's CHANGES.txt (above whatever the most recent "released" version is) and remove anything in the unreleased "4.x" section that is a duplicate. : trunk users not seeing the joint changes, however. We could just SVN people working off trunk don't really need to see changes committed to the 3x branch - they don't affect them unless they have aso been committed to the trunk - in which case they should already been mentioned. : Also, FWIW, I see very little reason to tote around a massive CHANGES : history. Do users really need to see the Lucene 1.1 CHANGES when they : download Lucene 4.0? I mean it's fun to see where we came from, but : that file is at 2500+ lines at this point. I'd propose we keep the last : release of the previous major release, plus all minor releases since. : Hence, 3.x would contain 2.9 plus 3.x. Personally, i relaly like having one uber long file in SVN that tracks all of this and is easy to grep -- i'd like to keep it as is, but i agree it's overkill for including in releases. I'd be totally on board with the idea that the CHANGES.txt file included in an X.Y release only includes changes committed in X.0 and above. -Hoss -- http://lucenerevolution.org/ ... October 7-8, Boston http://bit.ly/stump-hoss ... Stump The Chump! --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
