[rfc] six-month stable release cycles

[Martin Pool]

2009/8/1 Stephen J. Turnbull <stephen at xemacs.org>:
> Andrew Bennetts writes:
>  > 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,
>  >
>  > That's not my experience at all.
>
> Well, they may not keep the promise, but they certainly intend to make
> it.  I don't know internals about frameworks like Twisted and Zope to
> judge frequency of breakage, but anything that supports plug-ins and
> user-provided call-backs is likely to run into compatibility issues, I
> think, because those mechanisms themselves are often somewhat delicate
> because they provide additional semantics around the pure Python call.

We make a promise of backwards compatibility too, though we too do not
always manage to keep it.  If you just call public bzrlib APIs you
will generally get sensible warnings and a deprecation period, except
when we make a mistake.  Generally only small changes are needed too,
but it's enough to cause ripple effects.  When Ubuntu changes its
default Python version quite a few bugs are filed against affected
packages.  When Launchpad as a large Python application system moves
to a new server OS release it's a lot of work.

I think if Python was shipping new features every month and
distributions shipped different selections from that series we would
see similar problem to those Bazaar is trying to address with
six-month cycles.

I said Python can't make 'strong promises'; I would stand by that for
sufficiently large values of 'strong' but it was a bit of a throwaway
comment.

> My own experience with true applications, specifically Mailman and
> Roundup, however, is that backward compatibility issues with Python
> usually turn out to be bugs in the application that were masked by
> bugs in Python.

It can be argued (see the recent 'merge --preview' qbzr bug) that
plugins broken by bzrlib upgrades are buggy too.  But if the user is
left without a working setup this sounds like blame shifting.
(Exhibit A, many posts by Russel.)

-- 
Martin <http://launchpad.net/~mbp/>