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 namespace. 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
