Bazaar spontaneously unusable

[Brian de Alwis]

Sounds like bzr's API version should be decoupled from the release number.

Could I suggest that bzr adopt the semantics associated with the OSGi version numbering scheme?  It's a triple too, of the form major.minor.micro:

	major: incremented on nonbackwards compatible changes
	minor: incremented on backwards-compatible changes
	micro: bug fix (no API change)

There's also an optional .qualifier, mostly used to encode build numbers or build dates.  This fits easily with bzr's current scheme.

OSGi bundles then specify their requirements as version ranges, which can be open or closed, such as [1.18.2,1.19) meaning any version from 1.18.2 to anything except for the next minor release.  So if we started this policy now, with the bzr API at 2.2.0, then qbzr could specify [2.2.0,3) and live quite happily for the forseeable future, but correctly "break" when used with a future client where the API have been significantly changed.  There's a bit more in the following blog post:

    <http://www.osgi.org/blog/2009/12/versions.html>

Another blog entry by the same author looks at supporting backwards compatibility.  He notes that it may be worth having different version numbers to distinguish between interface compatibility (of concern to qbzr) from implementation compatibility (of concern to bzr-svn, bzr-git).

    <http://www.osgi.org/blog/2010/01/backward-compatibility.html>

Brian.

On 25-Mar-2010, at 8:19 AM, Ian Clatworthy wrote:

> Russel Winder wrote:
>> I appreciate that using bzr.dev is bleeding edge but the recent change
>> of bzrlib version has rendered a number of plugins unusable:
>> 
>> Unable to load plugin 'svn'. It requested API version (2, 1, 0) of module <module 'bzrlib' from '/home/Checkouts/Bazaar/Bazaar/Mainline_Working/bzrlib/__init__.pyc'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0)
>> Unable to load plugin 'git'. It requested API version (2, 1, 0) of module <module 'bzrlib' from '/home/Checkouts/Bazaar/Bazaar/Mainline_Working/bzrlib/__init__.pyc'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0)
>> Unable to load plugin 'rewrite'. It requested API version (2, 1, 0) of module <module 'bzrlib' from '/home/Checkouts/Bazaar/Bazaar/Mainline_Working/bzrlib/__init__.pyc'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0)
>> Unable to load plugin 'loggerhead'. It requested API version (2, 1, 0) of module <module 'bzrlib' from '/home/Checkouts/Bazaar/Bazaar/Mainline_Working/bzrlib/__init__.pyc'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0)
> 
> Personally, I'm not a fan of our "default to failure" approach. I find
> this truly annoying and think it's an anti-pattern.
> 
> Surely we can engineer a robust system without breaking half of our
> popular plugins every six months like this? Our current process doesn't
> scale. Imagine the scenario if we had 10 times as many plugins as now.
> I'm certainly pleased that my Firefox plugins continue working 99% of
> the time after each new Firefox release.
> 
> Ian C.
>