[rfc] six-month stable release cycles

[Stephen J. Turnbull]

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.

I'm not saying Bazaar doesn't do as well, modulo maturity and
resources, etc; I'm not competent to judge that.

 > but we can at least have a stable 2.x.1

Actually, there's a major difference.  Python somehow manages to put
substantial resources into maintaining stable branches; I see no
appetite for that among the bzr developers.  I do see an appetite for
quality control and making each release as stable as possible, and
that is one path to excellence, especially when you're on as tight a
resource budget as Bazaar is -- but that's not the same thing as
maintaining a stable branch.

I think this *is* a good time for Bazaar to start working toward the
goal of maintaining a stable branch, but both from the point of view
of resources and from the point of view of developing a rockin' VCS
(ie, as good as bzr is, there's more that everybody wants to do,
right?), it's going to take some time to achieve it.  That's why I
like the clean, minimalist approach you're presented.  It's a good
start, it *will* contribute to real stability for some users (although
it does require additional thinking of many distro maintainers,
they'll live -- and there's always the Tijuana option ;-), and it
won't take a huge amount of resources as currently proposed.