lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Solr CHANGES 3.1, 4.0
Date Fri, 10 Sep 2010 20:18:24 GMT

On Sep 8, 2010, at 8:50 PM, Yonik Seeley wrote:

> So, it looks like we should follow Lucene's lead on how to handle our
> across 3.x and trunk.  If the same change is being committed to both,
> put it in the 3.x
> section of trunk's CHANGES.

And the 3.x section of trunk's CHANGES is where in trunk?  I suppose we need to copy it over.

>  When something is backported to 3.x, move it from
> the 4.0 to the 3.1 section in trunk's CHANGES.  That will handle most
> of the issues
> I think.
> Of course... when a 3.x-only change is made, should that be added to the
> 3.1 section of trunk's CHANGES?

Instead of maintaining two places to edit, why don't we just have trunk track only those things
that are exclusive to trunk?  Anything that is committed to both goes in the X.Y version (i.e.
3.x).  Then, when it is released, we can just copy it over to trunk.  That has the downside
of trunk users not seeing the joint changes, however.  We could just SVN external in the previous
version CHANGES, too, or simply put a link to it in the trunk CHANGES, as in see http://xxxxx
for 3.x changes.  Thus, trunk contains only the trunk changes and then a pointer to the 3.x

Also, FWIW, I see very little reason to tote around a massive CHANGES history.  Do users really
need to see the Lucene 1.1 CHANGES when they download Lucene 4.0?  I mean it's fun to see
where we came from, but that file is at 2500+ lines at this point.  I'd propose we keep the
last release of the previous major release, plus all minor releases since.  Hence, 3.x would
contain 2.9 plus 3.x.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message