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
