Greets, As we've been working towards a release of the current KS trunk to CPAN as a non-dev tarball, I've been continuing to ponder backwards compatibility strategies, and I've come up with what I hope is an improved plan.
As expressed in the prior thread, I strongly believe that we should not just up and break back compat on current KS "stable" branch users. However, backwards compatibility is a feature, and not everyone needs it to the same degree. In particular, active developers tend not to need strict API compatibility -- it's not that hard to update your code so long as features you're counting on aren't outright removed. The mechanism by which we were going to protect stable branch users was to move trunk to the namespace "KinoSearch2". However, the downside of this stratagem is that the people forced into awkward namespace adjustments are the most active contributors. Should Peter Karman, who just released Search::Query::Dialect::KSx, rename that to use "KS2x" to indicate which version of KS his extension is compatible with? That's backwards -- we should reward be rewarding our most valuable developers, not foisting inconveniences on them while providing less active users with a convenience they may not need. One alternative is to release "stable" branches into new namespaces, while keeping svn trunk named "KinoSearch" in perpetuity: "KinoSearch0" was under consideration, but now I'm thinking we could fix a couple Unicode bugs, require re-indexing and call it "KinoSearch1". People for whom API backwards compatibility was a requirement would find it there. People who need the latest features can simply use "KinoSearch". One problem is that when we release into a new namespace, extensions such as Peter's probably won't work with it. However, extension developers will have the option of doing basically the same thing as us: releasing stable branches into a new namespace, updating those for bugfixes only, while continuing to focus new feature development on current trunk. There would also be a natural process of attrition when extension developers drift towards inactivity -- they release a version of their extension that syncs with the last stable release of the main library during their active period. This isn't a perfect solution, but I think it's at least a satisfactory way to resolve the current situation. The "stable" branch has been highly stable for a long time, but those users were still warned by that prominent ALPHA warning at the top of the docs -- expecting them to make a one-time switch is acceptable. Given that it meets that threshold in my judgment... the technique of releasing stable branches into new namespaces is an interesting experiment to run. We know what will happen if we just break back compat, but I'd like to gather data on this alternative strategy to determine whether it makes sense for Lucy. Does anybody know if any other projects have ever used a similar release strategy? Marvin Humphrey
