On Thu, 17 Mar 2011, Yonik Seeley wrote: : Date: Thu, 17 Mar 2011 23:36:33 -0400 : From: Yonik Seeley <yo...@lucidimagination.com> : To: Chris Hostetter <hossman_luc...@fucit.org> : Cc: Lucene Dev <dev@lucene.apache.org> : Subject: Re: Lucene Solr 3.1 RC1 : : On Thu, Mar 17, 2011 at 11:18 PM, Chris Hostetter : <hossman_luc...@fucit.org> 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_40 and CHANGES. : 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 together. 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. -Hoss
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
