lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: [DISCUSS] The next Lucene/Solr release, aka 5.0 is the new 4.11
Date Thu, 18 Sep 2014 17:37:53 GMT
Hi Steve,

Robert is currently backporting the "non-critical" stuff from Lucene 5. There is some code
in 5.0, which is not ready to commit (like Lucene Stored Document's API). The approach above
was just done like that for ease of handling. In fact, Robert created a "big patch" between
trunk an branch_5x and removed all stuff that’s not ready for release. This would then be
committed to 5.x branch for release.

So the current workflow may be "untypical" but at the end was easier to handle than "reverting"
changes in trunk that are not ready to release.

We are not going to release the state of the branching today, it was just a step inbetween.
After Robert's hard work we will have a large number of changes in 5.0, especially those breaking
backwards compatibility (like the final move to Java 7 NIO.2). We are just inbetween at the
moment. Stuff that’s unfinished (like we removed WAR file in trunk, but in contrast have
no real Lucene Server with main() method, servlet free is not releaseable) were left out.


Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> -----Original Message-----
> From: Steve Rowe []
> Sent: Thursday, September 18, 2014 7:26 PM
> To: lucene dev
> Subject: [DISCUSS] The next Lucene/Solr release, aka 5.0 is the new 4.11
> On LUCENE-5944, Robert and Uwe discussed moving trunk to 6.x and
> “creating branch_5x”, which I understood to mean:
>    svn copy trunk branch_6x
>    svn move trunk branch_5x
> Today, Robert did:
>    svn copy branch_4x branch_5x
> and then Uwe did:
>    svn remove branch_4x
> I don’t think this is the way to go.  There is huge amount of deprecation
> removal that happened on trunk, which will have to be repeated on
> branch_5x prior to a release.
> How about we go with releasing what was trunk before today as 5.0?  That
> will have the same backcompat result as Robert/Uwe’s approach.
> Steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: For additional
> commands, e-mail:

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

View raw message