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 Sat, 11 Jun 2011 01:31:00 GMT

: Is this expected?  It seem more like a by-product of trying to keep
: things in sync.  I suppose that could be fixed with some good
: To simplify the process, I suggest we remove historic info from /trunk
: and add point people to the CHANGE in the current stable branch (3.x)
: -- when /trunk is moved to /branch_4x we would move everything there.

Agreed.  This is something Grant and i both advocated last year and didn't 
really get any feedback on.  Rather then trying to keep files on diff 
branches in sync (what folks seem to be doing now) or "copying forward" 
changes from release branches to the trunk (what we have done in the past) 
let's just keep the CHANGES.txt file on each branch constrained to the 
changes commited directly to that branch and point people to URLs where 
then can find info about other releases.

This is all great, but it's actaully not my main concern at all.

My main concern is that this process of *removing* entries from the 
"trunk" section of CHANGES.txt when merging those commits "back" to an 
earlier release branch is losing history and will dangerously misslead 
users who review the changes in a given branch.

Consider this hypothetical timeline...

* 3.2 is released
* 3.3 is released
* trunk is renamed branch_4x
* 4.0 is released off branch_4x
* a new trunk is created targeting 5.x
* LUCENE-8888 is created - critical bug affecting 3.3
* r8888888 is commited to branch_3x to fix LUCENE-8888
* 3.3.1 is released with fix for LUCENE-8888
* 4.1 is released 
* LUCENE-9999 is created - critical bug affecting all versions
* r999999 is commited to trunk to fix LUCENE-9999
* r999999 is merged back to branch_4x
* r999999 is merged back to branch_3x
* 3.3.2 is released with fix
* 4.1.1 is released with fix

...if each of those merges follows the process described (only list a 
change in the section for the oldest release merged to) then people could 
be under the mistaken impression that 4.0 is safe and not at risk 
for LUCENE-9999 because the issue is listed as fixed was in 

We got away with this kind of pattern in the past because we weren't 
creating new branches for major releases.  The only time we 
ran into a situations where we had an ${X}.${Y}.Z
bug fix release when there had already been an ${X+1}.Q release was the 
2.9.x/3.0.x bug fix releases where we side stepped the issue by having 
"lock step" bug fix releases and only listed a single set of changes for 
*both* releases on each branch -- but expecting that same pattern to work 
in all cases moving forward seems like a pipe dream.  we pulled it off 
back then because the "branches" we're nearly identical (just removed 
deprecations) so the bugs (and fixes) were nearly identical.

the 3x branch and trunk are differnet enough that not every bug/fix is 
going to fit into that same patterm -- some bugs are only going to affect 
some branches, and some bugs might affect both branches but require 
different fixes.  we need to document our changes in a way that accurately 
reflects what was fixed where, and if we move forward with this process of 
"remove changes from trunk when backporting to 3x" that's going to fuck us 
over down the road.

At a fundemental, philosophical, level i think that every release should 
list the changes commited to that *branch* since the last release that was 
an "ancestor" in the svn hierarchy.  When 4.0 comes out, it's "section" in 
CHANGES.txt should be labeled "Changes since 3.0"  not "Changes since 
3.{whatever-the-latest-3x-release-was}" and if/when 4.4 comes out it's 
section should be "Changes since 4.3" and if 4.2.7 comes out it's section 
should be "Changes since 4.2.6"  ... etc.

But i can understand that people might think that is stupid.  I can 
understand people thinking that if a feature was backported and released 
in 3.1, users who download 4.0 won't care that it was independently 
commited to that branch as well, so it shouldn't be listed as a "Change" 
in 4.0 -- maybe for "features" that makes sense.

Buf for bug fixes we really need to deal with this in a better way.  We 
need to track *every* bug fix made on a branch, even if they were 
backported to an earlier branch.


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

View raw message