: you just commit it to the version it was added. : : For example, if you are adding something to 3x and trunk, commit it to : the 3x section of trunk's CHANGES.txt : then when you svn merge, there will be no merge conflict, it will just work.
That assumes you know, before commiting to trunk, that it will (or wont) be backported to 3x. The approach (and the cleanness of the merges) completley breaks down if you start out assuming a feature is targetting 4x, and then later decide to backport it. it will also break down in even more fun and confusing ways if/when we have our first 4.0 release and then someone pushes for having a 3.42 feature release after that (to push out some high value features to people not yet ready to upgrade to 4.0) because the changes legitimately need to show up in both the 3.42 and 4.1 release notes. I've tried to raise these concerns several times in the past and gotten virtually no response... http://markmail.org/message/s6zq4e7aomanxulp http://search.lucidimagination.com/search/document/9a9b1327fe281305/solr_changes_3_1_4_0 I really think that the 4.0 section of CHANGES should list *every* change on the trunk prior to the 4.0 release, even if it was backported to 3.1 or 3.3 -- because fundementally the "changes" are not neccessarily identicle. A bug fix that has been backported may be subtley different because of the differneces between the branches. I also (still) agree with Ryan about the "historic record" nature of CHANGES.txt not making sense anymore now that we have multiple feature release branches going at once... >> Can we delete everything past line 441 in: >> https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/CHANGES.txt >> and add a comment saying to look at: >> https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/lucene/CHANGES.txt +1 -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
