incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Stable releases under new namespaces
Date Wed, 10 Mar 2010 04:57:26 GMT

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

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

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

Marvin Humphrey

View raw message