incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Stable releases under new namespaces
Date Mon, 15 Mar 2010 01:28:03 GMT
Hello, Father...

We can help you by releasing a KinoSearch3 stable fork.  If keeping your
extension modules and code bases up to date with KS trunk is no longer
workable for you, we can at least give you a stable platform to work with that
supports all the features you've been using.

What we can't do is mimic Perl 5 and provide you with perpetual backwards
compatibility under the namespace "KinoSearch".  KinoSearch/Lucy must continue
to progress, and that will sometimes mean breaking back compat.

On Sat, Mar 13, 2010 at 02:29:49PM -0800, wrote:

> On Mar 12, 2010, at 10:16 AM, Marvin Humphrey wrote:
> >  KinoSearch1 1.00    <-- branches/ks1
> >  KinoSearch3 3.00    <-- branches/ks3
> >  KinoSearch  4.00    <-- branches/maint-4.x
> >  KinoSearch  5.00_01 <-- trunk
> One of the problems with this approach is that, if I want to use  
> KinoSearch 4.00 stable, I would have to start with ‘KinoSearch’ and  
> later migrate my code to ‘KinoSearch4’.

The plan in the quote above is an alternate which I also had problems with but
was exploring for the purpose of argument.  With multiple objections having
been lodged against it now, I think we can rule it out.

The original plan doesn't suffer from the defect you describe.

> Another problem with the all the multiple namespace suggestions so far  
> is that it makes it hard for KSx:: authors. 

In some sense, it's hard for KSx authors no matter what unless we adopt
perpetual backwards compat as a policy (which has its own downside, of
course).  You are having difficulties right now because the main library has
moved out from underneath you and you have multiple installs with slightly
different APIs to support.  This problem has arisen *without* us releasing
stable forks into new namespaces.

> How would I write a KSx::  module that works with multiple KinoSearch
> versions? 

I'd recommend against doing so.

KSx modules should target the current "KinoSearch" release only -- they should
not work KinoSearch1, KinoSearch3 or other stable forks.  If you want to
support KinoSearch3, release a back-fork into KS3x.  If you get tired of
perpetually modifying an extension to keep up with trunk, move it to the last
stable branch and go inactive.

Note that the alternative is for us to migrate trunk to the namespace
"KinoSearch2", in which case you'd have to fork your module into KS2x to work
with the *new* branch.  So keeping up with the main library while providing
back compat for older versions involves roughly the same amount of forking no
matter what.  

> Would I have to  keep releasing a new KS3x:: or KS4x:: whenever there is a
> new KinoSearch release?

Whenever there is a major version increment, yes.  But the ongoing support
burden should not be that great.

It would be up to you whether you ever wanted to fix bugs on one of those
forks, for example.  Unless it's something really serious, I wouldn't bother.

Though there won't be anything stopping people from developing against a
stable fork like KinoSearch3 from the get-go, these forks are mostly a way to
insulate mature, immobile code bases from the changes on trunk.  I doubt we'll
back-port features for them, just as we haven't back-ported improvements to
stable-branch KinoSearch 0.1x over the last two years.  So there will be
almost no churn, and thus very little potential for breakage due to changes in
the main library.

> Right now I’m having a maintenance nightmare, as two separate websites  
> are using different versions of KinoSearch that are no longer on CPAN.  
> And I haven’t had time to update the code for either of them.... And I  
> need to update my KSx modules, too. I’m just looking for a way to make  
> this all much easier.

I understand and I want to help.  You haven't been very active lately, but
historically you have made many valuable contributions.  I want to make sure
that we don't abandon you, the same way I want to make sure we don't abandon
MojoMojo or Socialtext.

To clear up the situation, all these code bases will need to be synchronized
on *some* version of KS.

You could bring them all up to the current KinoSearch trunk, then just avoid
upgrading your installed KinoSearch or KSx modules.  That's similar to what
you'd have to do if we simply broke back compat at major version increments.
(The fact that you have to resort to such techniques is a consequence of
Perl's dynamic loading mechanism, which as you know does not allow multiple
versions of the same library to co-exist.)

You could bring them all up to the current KinoSearch trunk, and keep them
up-to-date as the library evolves.  As you already are aware, this involves a
certain amount of ongoing work which active users accept, but is troublesome
for inactive users.

Or you could move them over to a stable fork, which will involve the least
amount of ongoing work once the transition is complete.  You won't get the
latest, greatest features anymore, but that may not matter -- the stable fork
may offer you all the features you need and serve as a sufficient development
platform for a long time to come.

I think this last option is your best one, and I'm willing to help by moving
towards a KinoSearch3 3.0 release.

Marvin Humphrey

View raw message