← 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
  • Date: 2005-09-15 21:35:53 UTC
  • mfrom: (907.1.57)
  • mto: (1393.2.1)
  • mto: This revision was merged to the branch mainline in revision 1396.
  • Revision ID: john@arbash-meinel.com-20050915213552-a6c83a5ef1e20897
(broken) Transport work is merged in. Tests do not pass yet.

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
 
.. _plugins: plugin-api.html
20
 
 
21
 
 
22
 
.. contents::
23
 
 
24
 
 
25
 
Motivation
26
 
==========
27
 
 
28
 
To allow plugins to apply their own policy for compatibility with bzrlib,
29
 
without requiring a new release on every library release. Plugins should
30
 
also be able to use the API to export their own compatibility information
31
 
for code reuse between plugins.
32
 
 
33
 
 
34
 
Terminology
35
 
===========
36
 
 
37
 
An **API** is a collection of python objects/modules/packages which can be
38
 
used by plugins and scripts. The ``bzrlib`` **API** covers all of bzrlib,
39
 
but we can be more precise - e.g. the ``WorkingTree API``.
40
 
An **API version** is a tuple ``(major, minor, point)``.
41
 
 
42
 
 
43
 
API versions
44
 
============
45
 
 
46
 
For simplicity we treat API's as being compatible with a range of
47
 
versions: the current release of the API, and some oldest version which is
48
 
also compatible. While we could say that there is a set of older versions
49
 
with which the current version is compatible, a range is easier to
50
 
express, and easier for a human to look at and understand, and finally
51
 
easier to manage. The oldest version with which the API for a python
52
 
object is compatible is obtained by looking up the ``api_minimum_version``
53
 
attribute on the python object handed to ``require_api``, and failing that
54
 
the bzrlib ``api_minimum_version`` is returned. The current version of the
55
 
API is obtained by looking for an ``api_current_version`` attribute, and
56
 
if that is not found, an ``version_info`` attribute (of which the first 3
57
 
elements are used). If no current version can be found, the bzrlib
58
 
``version_info`` attribute is used to generate a current API version.
59
 
This lookup sequence allows users with simple setups (and no python style
60
 
``version_info`` tuple) to still export an API version, and for new API's
61
 
to be managed more granularly later on with a smooth transition -
62
 
everything starts off in lockstep with bzrlib's master version.
63
 
 
64
 
API versions are compared lexically to answer the question 'is
65
 
the requested version X <= the current version, and >= the minimum
66
 
version'.
67
 
 
68
 
Managing API versions
69
 
=====================
70
 
 
71
 
The minimum API versions should be adjusted to the **oldest** API version
72
 
with which client code of the API will successfully run. It should not be
73
 
changed simply because of adding things in a compatible manner, or
74
 
deprecating features, but rather when errors will occur if client code is
75
 
not updated.  Versions for API's from ``bzrlib`` are given the version
76
 
numbers that ``bzrlib`` has had for consistency. Plugins should also take
77
 
this approach and use the version numbering scheme the plugin used.
78
 
 
79
 
Exported API's
80
 
==============
81
 
 
82
 
Currently we export a single API - the ``bzrlib API`` - and no finer
83
 
grained APIs. The API versioning support was introduced in bzrlib 0.18.
84
 
For plugins or tools that want to dynamically check for the presence of
85
 
the API versioning API, you should compare ``bzrlib.version_info[0:3]``
86
 
with ``(0, 18, 0)``.
87
 
 
88
 
+------------+---------------+
89
 
| API        | Covers        |
90
 
+============+===============+
91
 
| bzrlib     | All of bzrlib |
92
 
+------------+---------------+
93
 
 
94
 
Use Cases
95
 
=========
96
 
 
97
 
Some examples of using the API.
98
 
 
99
 
Requiring bzrlib 0.18 in a plugin
100
 
---------------------------------
101
 
 
102
 
In the plugins __init__.py::
103
 
 
104
 
  import bzrlib
105
 
  from bzrlib.api import require_api
106
 
  from bzrlib.errors import IncompatibleAPI
107
 
  try:
108
 
    require_api(bzrlib, (0, 18, 0))
109
 
  except IncompatibleAPI:
110
 
    raise ImportError("A bzrlib compatible with 0.18 is required.")
111
 
 
112
 
Exporting an API from a plugin
113
 
------------------------------
114
 
 
115
 
In the plugin ``foo`` exporting the API (in __init__.py)::
116
 
 
117
 
  version_info = (0, 0, 1, 'beta', 1)
118
 
  api_version = (0, 0, 1)
119
 
 
120
 
In a plugin depending on that plugin (in __init__.py)::
121
 
 
122
 
  import bzrlib.plugins.foo
123
 
  from bzrlib.api import require_api
124
 
  from bzrlib.errors import IncompatibleAPI
125
 
  try:
126
 
    require_api(bzrlib.plugins.foo, (0, 0, 1))
127
 
  except IncompatibleAPI:
128
 
    raise ImportError("A bzrlib compatible with 0.0.1 is required.")
129
 
 
130
 
 
131
 
..
132
 
   vim: ft=rst tw=74 ai
133