Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of rcmuir@gmail.com designates
 209.85.214.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=JVVeNJYwNjN8iLtAWerzyyJYE58ow+Rxq4PP2co3Zvia/Ze67ASXWlZfvEqwts0W/E
         ZHwHEtFh6vuImTrFVDYmR6OB+dporVDPIBPVZ649E0KTYN8mjDAaWODQk4Qc8IFfc/EH
         gpRb4sI47l2hG9eUK2K9J1+r+AHW0nfYnO2OM=
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1106091330140.20183@bester>
References: <BANLkTinwN5fAw5sE7w-r=cJhyzWmhFjJwg@mail.gmail.com>
 <BANLkTi=vhs++PvqG2gPNDoTsu3cxKZr3mg@mail.gmail.com>
 <alpine.DEB.2.00.1106091211310.20183@bester>
 <BANLkTin7TcJ0x0GKxABXr0JzWS5iO+1qzQ@mail.gmail.com>
 <alpine.DEB.2.00.1106091330140.20183@bester>
From: Robert Muir <rcmuir@gmail.com>
Date: Thu, 9 Jun 2011 16:59:55 -0400
Message-ID: <BANLkTi=UEsHYwRsB+-B58e3f4JcuBh4Q1w@mail.gmail.com>
Subject: Re: managing CHANGES.txt?
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 9, 2011 at 4:44 PM, Chris Hostetter
<hossman_lucene@fucit.org> wrote:
>
> : > The approach (and the cleanness of the merges) completley breaks down=
 if
> : > you start out assuming a feature is targetting 4x, and then later dec=
ide
> : > to backport it.
> :
> : you just first move your change to the 3.x section?
>
> so you're saying that to backport something from trunk to 3x you're
> saying the process should be:
> =C2=A0* first you should commit a change to trunk's CHANGES.txt moving th=
e
> previously commited entry to the appropraite 3.x.y section
> =C2=A0* then you should merge the *two* commits to the 3x branch
>
> ?

I think so? I guess in general, most things unless they are
super-scary tend to get backported immediately to 3.x (and you know
up-front you are going to do this) so in practice this hasn't been a
problem?

>
> : we already raised this issue and decided against it for a number of
> : reasons, it was raised on the dev list and everyone voted +1
> :
> : http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discus=
sion_trunk_and_stable_release_strategy#67815ec25c055810
>
> i contest your characterization of "everyone" but clearly i missed that
> thread back when it happened. =C2=A0That only address the issue of 3.x fe=
ature
> releases after 4.0 comes out -- but it still doesn't address the porblem
> of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be =
a
> serious problem if we keep removing things from the trunk CHANGES.txt whe=
n
> backporting.

OK, well everyone that did vote, voted +1. If you disagree please
respond to that thread! I think it would make things confusing if we
released 4.0 say today, then released 3.3 later, and 4.0 couldnt read
3.3 indexes... but please reply to it.

As far as bugfix releases, in lucene we have always had this issue
(e.g. if we do 3.2.1 we have the issue now). Thats why we have in our
ReleaseTODO a task where we deal with this (and i noticed it had been
missing from one of the bugfix 3.0.x releases and fixed that for 3.2).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org