lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <>
Subject Re: managing CHANGES.txt?
Date Thu, 09 Jun 2011 22:09:32 GMT
>> : we already raised this issue and decided against it for a number of
>> : reasons, it was raised on the dev list and everyone voted +1
>> :
>> :
>> i contest your characterization of "everyone" but clearly i missed that
>> thread back when it happened.  That only address the issue of 3.x feature
>> releases after 4.0 comes out -- but it still doesn't address the porblem
>> of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a
>> serious problem if we keep removing things from the trunk CHANGES.txt when
>> backporting.
> OK, well everyone that did vote, voted +1. If you disagree please
> respond to that thread! I think it would make things confusing if we
> released 4.0 say today, then released 3.3 later, and 4.0 couldnt read
> 3.3 indexes... but please reply to it.

The release strategy and CHANGES strategy seem different (but related)
to me.  I agree with the release strategy outlined in that thread, but
don't see how it answers questions about maintaining CHANGES.txt

The thing that seems wierd is that the historic release info in
CHANGES.txt is potentially different then what will presumably be
released in the 3.x branch.  For example right now, if you take the
3.x lucene/CHANGES and paste them in the right place on trunk, there
there are a bunch of diffs for names with accents
-   have been deleted. (Christian Kohlsch├╝tter via Mike McCandless)
+   have been deleted. (Christian Kohlschⁿtter via Mike McCandless)

but also real differences like:
-* LUCENE-2130: Fix performance issue when FuzzyQuery runs on a
-  multi-segment index (Michael McCandless)

The same exercise in solr/CHANGES.txt reveals lots of differences.

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.


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

View raw message