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 Tue, 21 Jun 2011 17:09:07 GMT

: I think we have?
: bugfixes are the only case (assuming we go with the plan where we
: don't go back in time and issue 3.x feature releases after we release
: 4.x, etc) where we "go backwards".

So you're saying after 4.0 is released, we'll stop "removing" changes 
entries from the 4x section when they are backported to the 3x branch?

I guess that will work -- but it seem fundementally and philosophically 
wrong to me to be doing this.

: I'll pick LUCENE-3042 as a random one.
: Its in Lucene 3.2's CHANGES.txt
: Its in branch-3.0's CHANGES.txt
: its in branch-2.9's CHANGES.txt
: its not in trunk's CHANGES.txt, since its fixed in a non-bugfix
: release before 4.0 will be released.

But there is no way for someone looking at the CHANGES for 4.0 to know 
for certain that the bits that make up that bug fix are in the 4.0 release 
-- the fact that it's listed in 3.2's CHANGES isn't an assurance, because 
4.0 comes from a completely different line of development.

: In short, I don't think there is any problem... and as far back as I
: can see, this is exactly how we have been handling all bugfixes with
: the 2.9.x and 3.0.x bugfix releases.

when we had a singular trunk producing the 2.9, 3.0, and 3.1 releases 
everything was linear and this type of linear CHANGES made sense -- but 
with two branches whose common ancestor is (essentially) 3.0 it just isn't 
the same thing - CHANGES should reflect *everything* that went into the 

For the same reason that 3.6 release notes would list all "changes 
since 3.5" and 3.6.1 release notes would list all "changes since 3.6" 
the release notes for 4.0 should list *all* "Changes since 3.0" since 
that's the common ancestor.

But to hell with it ... i've been arguing this for months and no one seems 
to agree, so fuck it.  

I'll stop harping on it but i can't promise i'll remember/understand the 
right way to add CHANGES to fall in line with the madness that's already 
in progress -- continued cleanup may be needed if/when i commit stuff that 
wins up backported.


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

View raw message