lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <>
Subject RE: CHANGES.txt
Date Mon, 27 Apr 2009 15:35:41 GMT
Thank you, Mike, for working to make things better.


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
> <> wrote:
> > On Fri, Apr 24, 2009 at 7:17 PM, Steven A Rowe <>
> 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:
For additional commands, e-mail:

View raw message