← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/api-versioning.txt

  • Committer: John Arbash Meinel
  • Author(s): Mark Hammond
  • Date: 2008-09-09 17:02:21 UTC
  • mto: This revision was merged to the branch mainline in revision 3697.
  • Revision ID: john@arbash-meinel.com-20080909170221-svim3jw2mrz0amp3
An updated transparent icon for bzr.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/api-versioning.txt
 
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``
 
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
 
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