Thank you, Mike, for working to make things better. Steve
On 4/27/2009 at 5:32 AM, Michael McCandless wrote: > 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
