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 19:22:33 GMT

: you just commit it to the version it was added.
: For example, if you are adding something to 3x and trunk, commit it to
: the 3x section of trunk's CHANGES.txt
: then when you svn merge, there will be no merge conflict, it will just work.

That assumes you know, before commiting to trunk, that it will (or wont) 
be backported to 3x.

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.

it will also break down in even more fun and confusing ways if/when we 
have our first 4.0 release and then someone pushes for having a 3.42 
feature release after that (to push out some high value features to people 
not yet ready to upgrade to 4.0) because the changes legitimately need to 
show up in both the 3.42 and 4.1 release notes.

I've tried to raise these concerns several times in the past and gotten 
virtually no response...

I really think that the 4.0 section of CHANGES should list *every* 
change on the trunk prior to the 4.0 release, even if it was backported to 
3.1 or 3.3 -- because fundementally the "changes" are not neccessarily 
identicle.  A bug fix that has been backported may be subtley different 
because of the differneces between the branches.

I also (still) agree with Ryan about the "historic record" nature of 
CHANGES.txt not making sense anymore now that we have multiple feature 
release branches going at once...

>> Can we delete everything past line 441 in:
>> and add a comment saying to look at:



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

View raw message