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 Fri, 12 Mar 2010 18:16:29 GMT
On Thu, Mar 11, 2010 at 03:35:07PM -0600, Peter Karman wrote:
> Marvin Humphrey wrote on 3/9/10 10:57 PM:
> > 
> > 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.
> I've been delaying in my response to this because (a) it took me awhile to
> grok the idea, and (b) I've been trying to play through scenarios based on
> my desire to keep my KS extension modules happy.
> I *think* I understand the idea. I.e., KinoSearch 0.1x becomes KinoSearch1,
> KinoSearch 0.3x becomes KinoSearch3, etc. Is that right?

That's a slight improvement on what had in mind.  :) 

I had been thinking that 0.3x would become KinoSearch2.  (Really 0.20_xx
should have been KinoSearch2, but it's long gone.)  However, I like the idea
that 0.3x corresponds to KinoSearch3.

So, here's what would happen right away:

  CPAN now:
    KinoSearch 0.165    <-- branches/maint_0.1x/
    KinoSearch 0.30_083 <-- trunk[1]

  CPAN after:
    KinoSearch1 1.00    <-- branches/ks1
    KinoSearch  0.31    <-- trunk

However, I think we should put out a new stable release soonish, so that
people who need API stability don't have to go all the way back to KinoSearch1
(no field-based sorting, much slower, etc.).  After that happens, CPAN might
look like this:

    KinoSearch1 1.00    <-- branches/ks1
    KinoSearch3 3.00    <-- branches/ks3
    KinoSearch  0.40    <-- trunk

> I don't have the same personal commitment to back compat for my own modules,
> so I'll happy continue pegging them to whatever the latest CPAN version of
> KinoSearch is. 

Right, this is how we inconvenience active developers like yourself the least.
You aren't required to back-fork.  

However, if somebody else wants your module bad enough, they'll probably fork
it for you.  :)

> Until, of course, I hear from users of my module who can't/won't
> upgrade their KS installs and then I'm fine with a back-fork under a different
> namespace, as you're describing (I think).

And presumably the maintenance burden of that back-forked module would be
minimal, because the library that it's pinned to won't be moving.

> > Does anybody know if any other projects have ever used a similar release
> > strategy?
> I don't. Usually a project with abandons earlier user base by changing APIs at
> major releases levels, 

Right.  As discussed, I prefer not to leave formerly-active users in the
lurch.  However, your point suggests a slight variant on the plan above.

I'd been thinking that "KinoSearch" would have a perpetually unstable API, and
that we'd abandon all pretense that it would ever be stable.  However, we
could do as you say here and break API compatibility only at major release
points -- however, to avoid abandoning the earlier user base completely, we'd
spin off a renamed stable branch at each back-compat break.

If we did that, CPAN would look like this right away:

    KinoSearch1 1.00    <-- branches/ks1
    KinoSearch  1.00    <-- identical to branches/ks1 except for namespace
    KinoSearch  3.00_01 <-- trunk

We would then work to get trunk ready for a real version 3 release.  Once it
was published, CPAN would look like this:

    KinoSearch1 1.00    <-- branches/ks1
    KinoSearch  3.00    <-- branches/maint-3.x
    KinoSearch  4.00_01 <-- trunk

Then, in a year or so[2] when we release KinoSearch 4, CPAN would look like

    KinoSearch1 1.00    <-- branches/ks1
    KinoSearch3 3.00    <-- branches/ks3
    KinoSearch  4.00    <-- branches/maint-4.x
    KinoSearch  5.00_01 <-- trunk

I don't like that as much, though, for a couple reasons.  

First, it would further put off the day when the current trunk gets published.
You wouldn't like that, nor would my colleagues here at Eventful, nor would I.

Second, we'd have to hide development behind dev releases again -- I think it
would be too confusing to publish a distribution with a fluid API but a
version number greater than 1.0.

Hiding development behind dev releases thwarts one of the main rationales for
this plan: privileging active users over inactive ones.  We want as many
people as possible to be using svn trunk.

Generally, I suspect new users will find "KinoSearch" first.  If they see a
version number less than 1.0, they can't say they weren't warned when the API
changes out from underneath them.   Those for whom backwards compatibility is
important will then have the option of moving their code to a stable fork.
There may be features that aren't available on the stable fork, but that's
what privileging active users means!

Some people will discover "KinoSearch3" at the same time as "KinoSearch" and
perhaps assume that KinoSearch3 is the latest and greatest.  However, we can
put a prominent note at the top of the main documentation page to set them

> or does gymnastics to provide eternal backwards compat
> (the latter seems to be what Perl does).

The back-compatibility debates that rage on p5p were a big influence on this
proposed policy.  

Every time somebody suggests dropping a little-used misfeature that's holding
Perl back, the conservatives win the day and it stays.  But then chromatic[3]
points out that the people who are benefitting most from stringent back-compat
are the people who aren't actively contributing any more.

Under the proposed policy, we privilege and reward our most active users and
contributors.  However, we don't completely screw over people who were once
active but have since become inactive.  They are required to make a one-time
sweep through their code to use the spun-off stable branch.

This way, projects like MojoMojo and Socialtext -- which depend on KinoSearch
but may not control exactly when Perl modules get upgraded on a machine
running their software -- will be able to switch to a stable branch like
KinoSearch1 and avoid breakage.

Marvin Humphrey

[1] Technically 0.30_083 is based off of branches/0.30_08x, but it's pretty
    darn close to trunk.

[2] This is theoretical because I expect we'll have transitioned from 
    KinoSearch to Lucy by then, but it's useful to think about it this way
    because the plan under discussion will probably be used by Lucy in the

[3] For those who don't know, "chromatic" is a prominent Perl developer and

View raw message