bzr 2.1 retrospective

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> Many users now get bzr and the plugins as a set, with consistency
> ensured by some intermediate party such as the windows or mac package
> builder, or the distro packager.
> 
> So one thing we could do is just say "please deprecate things that
> were in the previous release rather than just removing them, if
> possible."  But perhaps someone has a better idea.
> 

Saying "deprecate for one series, but if it was deprecated in 2.1 it can
be removed in 2.2" is one option here.

I would tend to push more for "no unstable changes from rc1" sort of
level, expecting to have ~1month for devs to fix up plugins to get them
into the final release without deprecations or failures. That may not be
enough time, though.

I know Aaron expressed concern that the version check for betas is
'weak' given that we are more likely to change things in a beta.
However, I've found the exact version matching a net loss. At least from
a packaging perspective, I've been bitten far more by 'I need to modify
this plugin so that it will let itself run', than I've had broken
functionality.

Even using bzrtools, if 1 command breaks, but 20 are still functional,
that doesn't seem like a good tradeoff for users. Consider EAFP. What
would probably be best is to register a hook such that if we get a
failure, and the traceback includes a plugin, and that plugin has stated
it has only been vetted against versions X => Y of bzr, then we can
inform the user that they probably need to upgrade the plugin.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuC27IACgkQJdeBCYSNAAOZ4wCfTgT1m/bDkuGsZo20yTc4uC2N
aPEAoIYxv6pZW+yCwHFkSlD/PWP8l0yS
=2DpE
-----END PGP SIGNATURE-----