On 4/24/2009 at 6:24 PM, Michael McCandless wrote: > On Fri, Apr 24, 2009 at 5:44 PM, Steven A Rowe <sar...@syr.edu> wrote: > > On 4/24/2009 at 4:45 PM, Michael McCandless wrote: > > > On Fri, Apr 17, 2009 at 1:46 PM, Steven A Rowe <sar...@syr.edu> > > > wrote: > > > > - Five issues (LUCENE-1186, 1452, 1453, 1465 and 1544) are > > > > mentioned in both the 2.4.1 section and in the Trunk section. > > > > AFAICT, it has not been standard practice to mention bug > > > > fixes on a major or minor release (which Trunk will become) > > > > if they are mentioned on a prior patch release. > > > > > > Hmm -- I thought it'd be good to be clear on which bugs were > > > fixed, where, even if it causes some redundancy? [...] > > So the policy you're suggesting is: "When backporting bug fixes > > from trunk to a patch version, make note of the change in both > > the trunk and patch version sections of CHANGES.txt", right? > > > > Makes sense (though as I noted, this policy has never before been > > used) > > Hmmm. > > > , but why then did you include only 5 out of the 15 bug fixes > > listed under 2.4.1 in the Trunk section? > > Yeah good point... let me better describe what I've been doing, and > then we can separately decide if it's good or not! > > For tiny bug fixes, eg say LUCENE-1429 or LUCENE-1474, I often don't > include a CHANGES entry in trunk, because I want to keep the "signal > to noise ratio" higher at that point for eventual users upgrading to > the next major release. > > But then when I backport anything to a point release, I try very hard > to include an entry in CHANGES for every little change, on the > thinking that people considering a point release upgrade really want > to know every single change (to properly assess risk/benefit). > > When I release a point release, I then carry forward its entry back to > the trunk's CHANGES, and so then we see some issues listed only in > 2.4.1, which is bad since it could make people think they were in fact > not fixed on trunk. > > So what to do? > > 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? Steve --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
