2550.2.1
by Robert Collins
API Versioning proposal document. |
1 |
============== |
2 |
API Versioning |
|
3 |
============== |
|
4 |
||
5 |
Status |
|
6 |
====== |
|
7 |
||
8 |
:Date: 2007-06-26 |
|
9 |
||
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 |
|
16 |
written against. |
|
17 |
||
18 |
||
19 |
.. contents:: |
|
20 |
||
21 |
||
22 |
Motivation |
|
23 |
========== |
|
24 |
||
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. |
|
29 |
||
30 |
||
31 |
Terminology |
|
32 |
=========== |
|
33 |
||
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)``. |
|
38 |
||
39 |
||
40 |
API versions |
|
41 |
============ |
|
42 |
||
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`` |
|
2550.2.2
by Robert Collins
Add helpers to get api versions from objects. |
50 |
attribute on the python object handed to ``require_api``, and failing that |
51 |
the bzrlib ``api_minimum_version`` is returned. The current version of the |
|
52 |
API is obtained by looking for an ``api_current_version`` attribute, and |
|
53 |
if that is not found, an ``version_info`` attribute (of which the first 3 |
|
54 |
elements are used). If no current version can be found, the bzrlib |
|
55 |
``version_info`` attribute is used to generate a current API version. |
|
56 |
This lookup sequence allows users with simple setups (and no python style |
|
57 |
``version_info`` tuple) to still export an API version, and for new API's |
|
58 |
to be managed more granularly later on with a smooth transition - |
|
59 |
everything starts off in lockstep with bzrlib's master version. |
|
60 |
||
61 |
API versions are compared lexically to answer the question 'is |
|
2550.2.1
by Robert Collins
API Versioning proposal document. |
62 |
the requested version X <= the current version, and >= the minimum |
63 |
version'. |
|
64 |
||
65 |
Managing API versions |
|
66 |
===================== |
|
67 |
||
68 |
The minimum API versions should be adjusted to the **oldest** API version |
|
69 |
with which client code of the API will successfully run. It should not be |
|
70 |
changed simply because of adding things in a compatible manner, or |
|
71 |
deprecating features, but rather when errors will occur if client code is |
|
72 |
not updated. Versions for API's from ``bzrlib`` are given the version |
|
73 |
numbers that ``bzrlib`` has had for consistency. Plugins should also take |
|
74 |
this approach and use the version numbering scheme the plugin used. |
|
75 |
||
76 |
Exported API's |
|
77 |
============== |
|
78 |
||
79 |
Currently we export a single API - the ``bzrlib API`` - and no finer |
|
80 |
grained APIs. The API versioning support was introduced in bzrlib 0.18. |
|
81 |
For plugins or tools that want to dynamically check for the presence of |
|
82 |
the API versioning API, you should compare ``bzrlib.version_info[0:3]`` |
|
83 |
with ``(0, 18, 0)``. |
|
84 |
||
85 |
+------------+---------------+ |
|
86 |
| API | Covers | |
|
87 |
+============+===============+ |
|
88 |
| bzrlib | All of bzrlib | |
|
89 |
+------------+---------------+ |
|
90 |
||
91 |
Use Cases |
|
92 |
========= |
|
93 |
||
94 |
Some examples of using the API. |
|
95 |
||
96 |
Requiring bzrlib 0.18 in a plugin |
|
97 |
--------------------------------- |
|
98 |
||
99 |
In the plugins __init__.py:: |
|
100 |
||
101 |
import bzrlib |
|
102 |
from bzrlib.api import require_api |
|
103 |
from bzrlib.errors import IncompatibleAPI |
|
104 |
try: |
|
105 |
require_api(bzrlib, (0, 18, 0)) |
|
106 |
except IncompatibleAPI: |
|
107 |
raise ImportError("A bzrlib compatible with 0.18 is required.") |
|
108 |
||
109 |
Exporting an API from a plugin |
|
110 |
------------------------------ |
|
111 |
||
112 |
In the plugin ``foo`` exporting the API (in __init__.py):: |
|
113 |
||
114 |
version_info = (0, 0, 1, 'beta', 1) |
|
115 |
api_version = (0, 0, 1) |
|
116 |
||
117 |
In a plugin depending on that plugin (in __init__.py):: |
|
118 |
||
119 |
import bzrlib.plugins.foo |
|
120 |
from bzrlib.api import require_api |
|
121 |
from bzrlib.errors import IncompatibleAPI |
|
122 |
try: |
|
123 |
require_api(bzrlib.plugins.foo, (0, 0, 1)) |
|
124 |
except IncompatibleAPI: |
|
125 |
raise ImportError("A bzrlib compatible with 0.0.1 is required.") |
|
126 |
||
127 |
||
128 |
.. |
|
129 |
vim: ft=rst tw=74 ai |
|
130 |