Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20090329022015.GA28673@rectangular.com>
References: <20090323021034.GA2330@rectangular.com>
	 <9ac0c6aa0903240457p4b6078a6if5b058a480f84c55@mail.gmail.com>
	 <20090324222556.GA21092@rectangular.com>
	 <9ac0c6aa0903250438wfe7489bh9164e757d47581c1@mail.gmail.com>
	 <20090325163957.GA24796@rectangular.com>
	 <20090326214826.GA2620@rectangular.com>
	 <9ac0c6aa0903261631n7b931503o3274792b1b0d0ff@mail.gmail.com>
	 <20090329022015.GA28673@rectangular.com>
Date: Sun, 29 Mar 2009 09:33:59 -0400
Message-ID: <9ac0c6aa0903290633w6b9832a5u335356d8d04f6d78@mail.gmail.com>
Subject: Re: Snapshot
From: Michael McCandless <lucene@mikemccandless.com>
To: lucy-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 28, 2009 at 10:20 PM, Marvin Humphrey
<marvin@rectangular.com> wrote:

> Perl and CPAN do not support sane deprecation and backwards compatibility
> schisms at major versions. =A0As soon as an incompatible version of the l=
ibrary
> gets installed -- the timing of which you might not have control over -- =
apps
> start crashing immediately. =A0For a large library like KinoSearch or Luc=
y,
> 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. =A0However, the
> implementation details are not. =A0The PMC would probably like to see a r=
elease
> under "Apache Lucy" as soon as possible, but I don't want to botch someth=
ing
> like the DataWriter plugin interface and be stuck supporting a sub-standa=
rd
> 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. =A0Release a prototype with Lucy's feature set bu=
t not
> named "Lucy" -- we might as well use the name "KinoSearch" since it's sti=
ll got
> the "alpha" WARNING. =A0Declare that a 1.0 release, promising not to brea=
k
> backwards compatibility any more.
>
> Learn from the experience of the prototype release to optimize Lucy, whic=
h
> will see several "alpha" releases. =A0Make "drastic changes" like changin=
g the
> return value of Folder_Open_InStream() if need be.
>
> Then, release "Lucy 1.0" -- and promise the world that there will never b=
e a
> Lucy 2.0. =A0Promise that if we need to break back compat, we'll fork int=
o 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 w=
ould
> be called "Lucy 1.0" and "Lucy 2.0". =A0Since 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, licensi=
ng
> issues won't be a problem. =A0If that changes, we'll have to adapt, but I=
 hope
> we can still follow that basic outline.

OK.

Mike