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, 30 Jun 2011 22:02:45 GMT

: There's no sense in CHANGES being a 'rolling list', when someone looks
: at 4.0 they should be able to see whats DIFFERENT aka what CHANGED
: from the past release.

I agree completely, the disagreement is *which* past release the list 
should be relative to.

I don't know how many more ways i can say it: I believe that the list of 
changes for 4.0 should be labled (and contain) "Changes since 3.0" -- 
because that is the most recent "past release" sith a common development 

When we only had a single trunk and the 3.0 release branch was forked 
from the same place as the 2.9 release branch it made sense to think of 
the 3.0 changes list as "Changes since 2.9" because they were genuine 
success of eachother -- any code in 2.9 was by definition in 3.0 unless it 
was modified/removed by somehting listed in the 3.0 changes.

That is not going to be true for 3.3 and 4.0 (or 3.4 and 4.0, or 3.7 and 
4.0 or whatever our last 3.x release is before 4.0).  

The list of changes 
for a release should always make it clear *exactly* what is differnet 
between that release and the previous release with common "lineage" of 
source code -- it may sound weird, but it's what i believe and it's 
consistent with how we've done bug fix releases in the past -- they've 
refered to changes since their "parent" release, not since the last 
calendar release.

Since no one seems to agree with me on this, I've tried to let this go 
(twice!) by stating my position and conceeding that it's not concensus -- 
but if you keep reviving the argument, i'll happily keep restating my 


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

View raw message