OK I fixed CHANGES.txt to not have double entries for the same issue in 2.4.1 and trunk (ie, the entry is only in 2.4.1's CHANGES section).
And going forward, if a trunk issue gets backported to a point release, we should de-dup the entries on releasing the point release. Ie, before the point release is released, trunk can contain XXX as well as the branch for the point release, but on copying back the branch's CHANGES entries, we de-dup then. I'll update ReleaseTodo in the wiki. Thanks Steven! Mike On Sat, Apr 25, 2009 at 5:43 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > On Fri, Apr 24, 2009 at 7:17 PM, Steven A Rowe <sar...@syr.edu> wrote: > >>> Maybe even tiny bug fixes should always be called out on trunk's >>> CHANGES. Or, maybe a tiny bug fix that also gets backported to a >>> point release, must then be called out in both places? I think I >>> prefer the 2nd. >> >> The difference between these two options is that in the 2nd, tiny bug fixes >> are mentioned in trunk's CHANGES only if they are backported to a point >> release, right? >> >> For the record, the previous policy (the zeroth option :) appears to be that >> backported bug fixes, regardless of size, are mentioned only once, in the >> CHANGES for the (chronologically) first release in which they appeared. You >> appear to oppose this policy, because (paraphrasing): people would wonder >> whether point release fixes were also fixed on following major/minor >> releases. IMNSHO, however, people (sometimes erroneously) view product >> releases as "genetically" linear: naming a release A.(>B)[.x] implies >> inclusion of all changes to any release A.B[.y]. I.e., my sense is quite >> the opposite of yours: I would be *shocked* if bug fixes included in version >> 2.4.1 were not included (or explicitly called out as not included) in >> version 2.9.0. >> >> If more than one point release branch is active at any one time, then things >> get more complicated (genetic linearity can no longer be assumed), and your >> new policy seems like a reasonable attempt at managing the complexity. But >> will Lucene ever have more than one active bugfix branch? It never has >> before. >> >> But maybe I'm not understanding your intent: are you distinguishing between >> released CHANGES and unreleased CHANGES? That is, do you intend to apply >> this new policy only to the unreleased trunk CHANGES, but then remove the >> redundant bugfix notices once a release is performed? > > OK you've convinced me (to go back to the 0th policy)! Users can and > should assume on seeing a point release containing XXX that all future > releases also include XXX. Ie, CHANGES should not be a vehicle for > "confirming" that this is what happened. > > So if XXX is committed to trunk and got a CHANGES entry, if it a later > time it's back ported to a point release, I will remove the XXX from > the trunk CHANGES and put it *only* on the point releases CHANGES. > > Also, I'll go and fix CHANGES, to remove the trunk entries when > there's a point-release entry, if nobody objects in the next day or > so. > > Mike > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
