incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Snapshot
Date Sun, 29 Mar 2009 02:20:15 GMT
On Thu, Mar 26, 2009 at 07:31:45PM -0400, Michael McCandless wrote:

> It sure is nice you can still make such drastic changes :)

I can do that because I've artificially drawn out the "alpha" period for
KinoSearch, at the expense of its popularity and usefulness.

If I could go back in time, I would have declared the stable branch
"KinoSearch 1.0" a year or two ago, and forked the dev branch into another

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.

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.

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.  

Marvin Humphrey

View raw message