lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: managing CHANGES.txt?
Date Thu, 09 Jun 2011 20:59:55 GMT
On Thu, Jun 9, 2011 at 4:44 PM, Chris Hostetter
<> 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 decide
> : > 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:
>  * first you should commit a change to trunk's CHANGES.txt moving the
> previously commited entry to the appropraite 3.x.y section
>  * 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

> : 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
> :
> :
> i contest your characterization of "everyone" but clearly i missed that
> thread back when it happened.  That only address the issue of 3.x feature
> 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 when
> 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:
For additional commands, e-mail:

View raw message