On Sat, Mar 28, 2009 at 10:20 PM, Marvin Humphrey <[email protected]> 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. Gak. > 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 starters. 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. OK. Mike
