[rfc] stable releases and plugins

[Martin Pool]

A few thoughts on plugins going into stable releases, based on some
discussions last week:

We'd like to ship many plugins along with Bazaar in a way that meets
the user's expectations for a stable platform vs the latest new stuff.

We want to ship mutually consistent and stable sets of bzr and
associated things that remain for the lifetime of that branch.  By
'stable' I mean having a low risk of new bugs and a low risk of API
breakage, and by 'ship' I mean putting them into Ubuntu, the PPA,
Windows or Mac installers, or other distros.  We don't want to put
extra work on plugin authors.  We do want to ship a broad selection of
plugins.

To get there we would like to nominate, around the time of the bzr
release candidate, the branch of the plugin that will be stable for
that release.  This branch should get only bugfixes in the same way
the core does.

If the plugin author doesn't want to do a stable branch that's ok, but
we won't take non-bugfix changes after the first release candidate.
If there is no bugfix branch for the plugin, it will probably stay on
the same version we originally take.

We'd like to specifically check the versions of the plugins that will
be packaged separately from building the Windows installer, since the
latter is enough hard work already.  Specifically I'd like to check
that selftest passes for them at least on unix.  There is a list of
packaged plugins but maybe that should be made a bit less
windows-specific (if it is.)

I expect the plugin maintainers will welcome merge proposals into that
branch if packagers provide them.

I'd like to test doing this on say 2.2beta2 and then do it for real on
2.2rc1.  I'm not suggesting any big changes for process in 2.1 as it's
already underway.

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