bzr 2.1 retrospective

[Aaron Bentley]

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

John Arbash Meinel wrote:
> 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.

Actually, I don't want my plugins to *fail* because the API doesn't
match their demands-- I want them to *adapt* to the API that is present.

> Even using bzrtools, if 1 command breaks, but 20 are still functional,
> that doesn't seem like a good tradeoff for users.

Why should users have even 1 broken command they don't have to?

> 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.

That sounds potentially quite useful.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuDBAsACgkQ0F+nu1YWqI2B4gCfa5X/wA7in3PCuKhQEZg/IR9o
jUYAn0WdijmcRhXdh3qLzZOrna3xulCJ
=H7Q1
-----END PGP SIGNATURE-----