incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Snapshot
Date Sun, 29 Mar 2009 13:33:59 GMT
On Sat, Mar 28, 2009 at 10:20 PM, Marvin Humphrey
<> wrote:

> Perl and CPAN do not support sane deprecation and backwards compatibility
> schisms at major versions.  As soon as an incompatible version of the library
> gets installed -- the timing of which you might not have control over -- apps
> start crashing immediately.  For a large library like KinoSearch or Lucy,
> making backwards compatibility promises that you can keep is hard to do
> without stunting future development.


> In my mind at least, Lucy's feature set is pretty clear.  However, the
> implementation details are not.  The PMC would probably like to see a release
> under "Apache Lucy" as soon as possible, but I don't want to botch something
> like the DataWriter plugin interface and be stuck supporting a sub-standard
> API forever.

I think you should fear making such mistakes so much?  We make
mistakes all the time in Lucene, and we deprecate APIs and move on.
Still, I agree it'd be nice to get things as close to right for

Python does some sort of explicit versioning in C extensions compiled
for it.  So maybe Lucy could do something similar, on seeing a
DataWriter with the "old" API it could interact with it using the
"old" way.  Not pretty, but possible.

> At the same time, I don't want Lucy to live in limbo like KinoSearch has.
> So, here's my solution.  Release a prototype with Lucy's feature set but not
> named "Lucy" -- we might as well use the name "KinoSearch" since it's still got
> the "alpha" WARNING.  Declare that a 1.0 release, promising not to break
> backwards compatibility any more.
> Learn from the experience of the prototype release to optimize Lucy, which
> will see several "alpha" releases.  Make "drastic changes" like changing the
> return value of Folder_Open_InStream() if need be.
> Then, release "Lucy 1.0" -- and promise the world that there will never be a
> Lucy 2.0.  Promise that if we need to break back compat, we'll fork into a new
> namespace, "Lucas" or whatever.

So never release a Lucy 2.0 because CPAN can handle the distinction
(and will blindly break end-users installations by swapping out Lucy
1.x for 2.x)?

It would be nice to get source code checked into Lucy's svn sooner
rather than later...

> In a world where everybody supports sane versioning, these two releases would
> be called "Lucy 1.0" and "Lucy 2.0".  Since we don't live in that world, we
> need to name them something else.
> If I remain the sole contributor of code to Lucy for a while yet, licensing
> issues won't be a problem.  If that changes, we'll have to adapt, but I hope
> we can still follow that basic outline.



View raw message