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: Solr CHANGES 3.1, 4.0
Date Sat, 18 Sep 2010 00:50:56 GMT

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


Mime
View raw message