[rfc] six-month stable release cycles

[Andrew Bennetts]

Stephen J. Turnbull wrote:
> Martin Pool writes:
> 
>  > The Python case is a lot like ours, unsurprisingly - they basically
>  > can't and don't make strong promises about stability from 2.x to 2.y -
> 
> IMO, they do.  They make a strong promise of backward compatibility,
> and every time the minor version gets bumped, there are long
> discussions about just what backward compatibility means and whether
> certain changes preserve it.  Since 2.0, it's very rare for a pure
> Python application that works in 2.x to stop doing so in 2.(x+1).
> Where they've had problems is with C extensions.

That's not my experience at all.  Just off the top of my head, Twisted and
Bazaar have both needed work for basically every single new 2.x released in
their lifetimes, even ignoring C extensions.  Changes to the language itself are
typically very backwards compatible (__future__ imports help a lot there), but
changes to the standard library and even the core objects tend to cause
problems.

Python certainly tries, and as a result the changes necessary usually aren't
large, which is good.  And some unintentional breakages do get noticed and
addressed before the final 2.x release (such as some recent unittest changes in
Python trunk that originally broke the running of bzr's test suite).  I'd much
rather have this sort of best-effort backwards compatibility than none at all!
But I think it's much too strong to claim that breakages are “very rare”.

I think the fundamental problem for library authors is that Python (Python 2, at
least, I haven't used 3 enough to have an opinion about it) as a language simply
doesn't have good facilities for managing API evolution.  The line between
public and private symbols is usually very blurry, especially if you have any
part of your API designed to be used via subclassing.  It's very easy to make a
change without noticing that it has a side effect like suddenly requiring your
API to be passed hashable objects.  And so on.

-Andrew.