Lucene version numbers are about compatibility.
Minor versions should always have complete API back-compatiblity.
That's to say, any code developed against X.0 should continue to run
without alteration against all X.N releases. A major release may
introduce incompatible API changes. The transition strategy is to
introduce new APIs in release X.N, deprecating old APIs, then remove all
deprecated APIs in release X+1.0.
File formats are back-compatible between major versions. Version X.N
should be able to read indexes generated by any version after and
including version X-1.0, but may-or-may-not be able to read indexes
generated by version X-2.N.
Note that older releases are never guaranteed to be able to read indexes
generated by newer releases. When this is attempted, a predictable
error should be generated.
Does that sound reasonable?
Doug
karl wettin wrote:
On Wed, 2006-05-10 at 13:29 -0400, Grant Ingersoll wrote:
Or even Lucene3Whiteboard (did I really write Lucene 3?!?)
You know, I was just thinking that it would be nice if Lucene was
developed like the Linux kernels. When 2.6 is stable, people are beta
testing 2.7 and some hack 2.8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
