10
bzrlib has a rich API which is used both internally, and externally by
11
plugins and scripts. To allow the API to change, specifically to allow
12
support for features and methods to be removed, without causing hard to
13
diagnose bugs in the clients of the API, bzrlib provides explicit API
14
compatibility data, and a compact API to allow scripts and plugins to
15
ascertain if the bzrlib they are using is compatible to the API they were
25
To allow plugins to apply their own policy for compatibility with bzrlib,
26
without requiring a new release on every library release. Plugins should
27
also be able to use the API to export their own compatibility information
28
for code reuse between plugins.
34
An **API** is a collection of python objects/modules/packages which can be
35
used by plugins and scripts. The ``bzrlib`` **API** covers all of bzrlib,
36
but we can be more precise - e.g. the ``WorkingTree API``.
37
An **API version** is a tuple ``(major, minor, point)``.
43
For simplicity we treat API's as being compatible with a range of
44
versions: the current release of the API, and some oldest version which is
45
also compatible. While we could say that there is a set of older versions
46
with which the current version is compatible, a range is easier to
47
express, and easier for a human to look at and understand, and finally
48
easier to manage. The oldest version with which the API for a python
49
object is compatible is obtained by looking up the ``api_minimum_version``
50
attribute on the python object handed to ``require_api``. The current
51
version of the API is obtained by looking for an ``api_current_version``
52
attribute, and if that is not found, an ``version_info`` attribute (of
53
which the first 3 elements are used). If no current version can be found,
54
the bzrlib ``version_info`` attribute is used to generate a current API
55
version. API versions are compared lexically to answer the question 'is
56
the requested version X <= the current version, and >= the minimum
62
The minimum API versions should be adjusted to the **oldest** API version
63
with which client code of the API will successfully run. It should not be
64
changed simply because of adding things in a compatible manner, or
65
deprecating features, but rather when errors will occur if client code is
66
not updated. Versions for API's from ``bzrlib`` are given the version
67
numbers that ``bzrlib`` has had for consistency. Plugins should also take
68
this approach and use the version numbering scheme the plugin used.
73
Currently we export a single API - the ``bzrlib API`` - and no finer
74
grained APIs. The API versioning support was introduced in bzrlib 0.18.
75
For plugins or tools that want to dynamically check for the presence of
76
the API versioning API, you should compare ``bzrlib.version_info[0:3]``
79
+------------+---------------+
81
+============+===============+
82
| bzrlib | All of bzrlib |
83
+------------+---------------+
88
Some examples of using the API.
90
Requiring bzrlib 0.18 in a plugin
91
---------------------------------
93
In the plugins __init__.py::
96
from bzrlib.api import require_api
97
from bzrlib.errors import IncompatibleAPI
99
require_api(bzrlib, (0, 18, 0))
100
except IncompatibleAPI:
101
raise ImportError("A bzrlib compatible with 0.18 is required.")
103
Exporting an API from a plugin
104
------------------------------
106
In the plugin ``foo`` exporting the API (in __init__.py)::
108
version_info = (0, 0, 1, 'beta', 1)
109
api_version = (0, 0, 1)
111
In a plugin depending on that plugin (in __init__.py)::
113
import bzrlib.plugins.foo
114
from bzrlib.api import require_api
115
from bzrlib.errors import IncompatibleAPI
117
require_api(bzrlib.plugins.foo, (0, 0, 1))
118
except IncompatibleAPI:
119
raise ImportError("A bzrlib compatible with 0.0.1 is required.")
added
removed
doc/developers/api-versioning.txt
