incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karman <>
Subject Re: Stable releases under new namespaces
Date Sun, 14 Mar 2010 19:30:48 GMT wrote on 3/13/10 4:29 PM:

> Perhaps the ‘KinoSearch’ namespace could be a front end that delegates
> to a separate namespace. So ‘use KinoSearch 3;’ or ‘use KinoSearch api
> => 3’ would alias all the KinoSearch namespaces to KinoSearch3:: or
> KinoSearch::3:: for that process (or thread). Then a KSx module can call
> KinoSearch->api or api_version (perhaps this method could be on every
> object under KinoSearch::) to find out which version is being used. If a
> process needs to access multiple KinoSearch versions, it can use
> KinoSearch3 directly.
> Using KinoSearch without specifying a version will default to the
> latest, with a warning. ‘api => "*"’, ‘api => 0’ or ‘api => "latest"’
> could be used to suppress the warning.
> Now, for this to work seamlessly, all KinoSearch versions would have to
> be bundled along with the latest, which is a bit much. I think clear
> documentation that explains that KinoSearch2/3 needs to be installed
> separately (if it is an old version) is a sufficient compromise, as the
> ‘Can’t locate in @INC’ message explains exactly what’s
> wrong.

I like this approach. It's more work for KS developers, in terms of managing api
versions, but that's good work to do, since it requires making the api changes
very explicit.

Could put the api version in the schema.json file and provide clear error
messages when trying to read/write incompatible versions.

Peter Karman  .  .

View raw message