lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Lucene Solr 3.1 RC1
Date Fri, 18 Mar 2011 19:04:45 GMT
On Thu, 17 Mar 2011, Yonik Seeley wrote:

: Date: Thu, 17 Mar 2011 23:36:33 -0400
: From: Yonik Seeley <>
: To: Chris Hostetter <>
: Cc: Lucene Dev <>
: Subject: Re: Lucene Solr 3.1 RC1
: On Thu, Mar 17, 2011 at 11:18 PM, Chris Hostetter
: <> wrote:
: >
: > : A 1.4.2 release in development, yes.  That's the earliest point that
: > : the bug was fixed, and someone
: > : upgrading from 1.4.1 should look at everything after the 1.4.1 release.
: >
: > that makes no sense to me.  even if a 1.4.2 release is going ot exist at
: > some hypothetical point in the future, it doesn't exist *now* when the 3.1
: > release is coming out.  CHANGES.txt should only list real changes since
: > real releases.
: >
: > All of the things listed in the 1.4.2-dev section have actually been fixed
: > in the the 3.1 branch as well -- in fact, most of them (all but one i
: > think) are double listed in the 3.1 bug section of the CHANGES.txt
: >
: > We can't predict the future -- we don't know what else might get
: > included in a hypotheetical 1.4.2 release, so we're better off listing
: > nothing, then listing something that might be wrong.
: But it's listed as 1.4.2-dev (in development).
: I'm not sure exactly what you have in mind, but feel free to fix it..
: it's a really minor issue to me.

Committed revision 1083014.
Committed revision 1083015.

: I sort of adopted the lucene convention of how to deal with 3x and trunk.
: If you fix something in trunk and are going to immediately merge back
: to 3x, you put it in the 3x section of CHANGES in trunk and then merge
: back.

...and that still makes no sense to me ... 3.x and 4.x releases are not 
going to be sequential, successor releases along a single branch of code 
in the same way that 2.4 was a successor to 2.3.  a bug fix on the trunk 
is a differnet fix then a bug fic on the 3x branch, and they should be 
tracked accordingly.

If a bug was fixed on trunk in time for 4.0, and also merged to the 3x 
branch in time for 3.2, and a user upgrades directly from 3.1 to 4.2, 
we're doing them a disservice if that bug fix is only listed in the 3.2 
section of CHANGES.txt, because it implies that the fix in 3.2 is the fix 
they are getting, but it's not, they are not on a completley differnet 
code path (trunk), that may have been widely divergent from the 3x code at 
the time the bug fix was merged.

Liwise: if we continue to have active bugfix release on the 3x 
branch while moving forward with 4x feature releases, the entire 
model of "only list it in the section of earliest version it was 
backported to" completley breaks down.  a user upgrading from 
4.1 to 4.2 should be able to look at the CHANGES section for 4.2 and know 
about ever change that was made -- they shouldn't have to guess that some 
changes aren't listed becuase they were backported to a 3.x.y bug fix that 
happened the same week.

: Personally, I think it might be easiest to keep two files in trunk:
: CHANGES would always be identical to 3x, and you would update that if
: you were going to merge back to 3x.
: When it's time for release, CHANGES_40 and CHANGES could be put 

why bother trying to track the stuff in two places? ... when 3.1 comes out
we can completley blow away the 3.1 section of CHANGES.txt on trunk and
cut/paste the whole thing in from the official release.

the simplest solution is still to just commit to the "top" of CHANGES.txt 
on the branh where you commit the fix -- if you merge the fix to another 
branch, merge the CHANGES.txt entry too. then the CHANGES.txt of every 
release tracks exactly what changed on that code branch.

I see no particular value in having the CHANGES.txt distributed with a 
rleeasee contain a historical archive of every CHANGE ever made in ever 
release, but if people really want that it can be solved by a copy/paste 
to all of the other active branches at the time of release.


View raw message