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, [email protected] 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
