lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Lucene+Solr 3.x branch created
Date Tue, 04 May 2010 22:13:16 GMT
I forgot:

This affects of course "Solr" + "Lucene Java" with combined branch-3.x and trunk-4.0.

I will be on vacation for one week until next Wednesday! Sorry, hope all works fine!

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

> -----Original Message-----
> From: Uwe Schindler []
> Sent: Wednesday, May 05, 2010 12:04 AM
> To:
> Subject: Lucene 3.x branch created
> Hi all,
> we worked hard this day and created the "stable" Lucene 3.x branch that
> will be released soon as version 3.1 and later 3.x branches. As soon as
> 3.1 is released a corresponding "branch_31" will be created from this
> branch (and not trunk):
> This was created as the last commit pre-flex and also contains a lot of
> merged revisions from post-flex (like CharTermAttribute). This makes
> merging newer Analyzers/TokenStreams and so on easier. We also fixed
> some bugs shortly before flex so the stable branch is now stable. I
> also refactored the change log.
> Now the TODO is:
> - Merge the rest of post-flex developments like lots of analyzer
> improvements until current trunk status. This should ideally be done
> with a GUI tool that shows what was already been merged (these are lots
> of revisions, see merge property. Only selected revisions are merged).
> Most commits came from rmuir, he will also use TortoiseSVN (like I did
> for merge).
> - All these merges move in CHANGES.txt from trunk to the branch (in
> trunk changes.txt) and also are added to branch's changes.txt
> - Do the same refactoring of Solr's changes.txt (I did not touch until
> now), its out of my scope - somebody else should do this.
> I also added Hudson build jobs for this branch. We have now:
> The development of trunk will continue as usual @
> With Hudson jobs:
> !!! BUT !!!: It will be have no backwards compatibility, but still some
> revisions can be merged back (with added backwards layer! On a case-by-
> case basis). Flex and flex-only features will not be ported back (like
> automaton queries). This version will be released as 4.0 (this may also
> happen soon). This development branch is for all new developments
> without any need to be backwards compatible. Even the index format can
> change (and will). We will only provide a conversion tool that can
> convert indexes from the last "branch_3x" up to this trunk (4.0)
> release, so they can be read later, but may not contain terms with all
> current analyzers, so people need mostly reindexing. Older indexes will
> not be able to be read natively without conversion first (with maybe
> loss of analyzer compatibility).
> This index format conversion tool (has no name until now) will convert
> to the new flex format and may also change the order of terms in
> TermsEnum to be native byte[] order (which is Unicode code point order
> and not current UTF-16 order). Also numeric fields and collation keys
> may be converted to full 8 bit term format (not yet decided), that are
> no longer UTF-16 terms.
> We will also factor out all analyzers/tokenstreams, so trunk will only
> contain the abstract TokenStream and Analyzer base classes with
> slightly changed API. All the actual analysis classes will be moved to
> modules.
> Happy coding!
> Uwe
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> eMail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message