[ANN] bzr 2.3b1 released ! (bzr-beta-ppa updated; some plugins uninstallable)

[Martin Pool]

On 29 September 2010 00:37, Eric Siegerman <lists08-bzr at davor.org> wrote:
> On Sat, 2010-09-25 at 12:17 +1000, Martin Pool wrote:
>> Let's just declare that "we're 2.3b2" and
>> then plugins can decide if they want to assume they work with any
>> bzrlib, they work with bzr >=2.2, they need a special workaround for
>> some versions, or whatever.
>
> I may well be misremembering/misunderstanding, but ISTM that
> would get us back to the place where Aaron has to release a new
> bzrtools for every beta.  I thought that annoyance was one of the
> drivers for moving to the current scheme...

No, it doesn't.  Plugin authors have a choice about whether they want
to be optimistic about their plugins will work with future bzr
releases, or pessimistic and only declare compatibility with versions
that have been specifically tested.

Optimistic:
 * declare requirement for bzrlib >= x
 * if it turns out that y doesn't work with the plugin, it will just
fail (typically with a nameerror or attributeerror)
 * users may file bugs about these errors and need to be told to upgrade

Pessimistic:
 * declare requirement for bzrlib in [x..y]
 * fails to load with newer bzr
 * requires a new plugin release every time bzrib goes past the tested y
 * fails "cleanly" but will sometimes fail unnecessarily
 * users may complain there is no release

Aaron chooses to use the pessimistic appoach.  (I don't imply any
value judgement in these names, they just seem accurate.)  My feeling
is the former is a better tradeoff but I can't/won't force people to
do it.

In either approach, I think matching against the actual library
version is better than matching against an API level that may be
inaccurate.

In the pessimistic approach there is no reason the plugin needs to
check bzrlib == (2, 3, 'beta', 1).  They could just check it is
2.3.something.  If you really want to take a very pessimistic approach
and mark compatibility with a single beta it's possible but I think
that's a poor tradeoff.

-- 
Martin