Context Navigation

Roadmap

This page describes the current expected direction of future development of Xapian.
Please note that any future dates mentioned here are only estimates.

Release Policy

Releases are given three-part version numbers (e.g. 1.2.9), the three parts
being termed "major" (1), "minor" (2), and "revision" (9). Releases which
differ only in revision are termed a "release series".

For Xapian releases 1.0.0 and higher, an even minor version indicates a stable
release series (e.g. 1.0.x, 1.2.x), while an odd minor version indicates a development release
series (e.g. 1.1.x, 1.3.x).

Within a stable release series, we strive to maintain API and ABI forwards
compatibility. This means that an application written and compiled against
version X.Y.a of Xapian should work, without any source changes or need to
recompile, with a later version X.Y.b, for all b >= a.

Releases are not explicitly time driven, but we aim to make a release every one to two months.

Stable Releases

Within a stable release series, releases should be upwardly API and ABI compatible. They may introduce new features (so applications may need to depend on a release with at least a particular "revision" number if they need these new features).

Stable releases which increase the "minor" or "major" version number can change the API and/or ABI in incompatible ways, though we will
attempt to do this in a way which makes it reasonably easy to migrate applications, and document this in our
"deprecation" policy document.

We expect that it will typically be one to two years between stable release series, and one to two months between
releases within a release series.

Development Releases

The idea behind having a development release series is that it allows
users to easily try the latest and greatest code if they wish without worrying too much about the ground shifting
from under them. Those favouring stability over everything else can stay with the previous stable release series.

Xapian 1.1.x was our first development release series, and seemed to work well, so we're intending to continue
to adopt this approach. Should we ever decide to skip a development release series, we intend to skip the
odd minor number too (to try to avoid confusion).

In a development release series, API compatibility should be maintained between releases, except for features which
are explicitly marked as "experimental". ABI compatibility may not be maintained (so upgrading to a new release
may require a rebuild of user applications), but won't be broken without a good reason (so we'll try to "save up"
ABI incompatible changes).

The default backend will remain compatible between releases. If you're using the development backend ("chert"
for the 1.1.x series) you may need to rebuild databases from scratch after upgrading, but again we won't make
incompatible changes without a good reason.

We may also update the Unicode tables used to a newer version during a development release series (e.g. Unicode
5.2 was released while we were still working on 1.1.x, so we updated to it). Similarly for the Snowball
stemming algorithms. Such changes
will mean that rebuilding a database from the same data from scratch will give slightly different terms in some
cases, and similarly some queries will parse to give different terms, but the cases of difference should be
rare and fairly obscure, and such cases generally won't have worked well before the change, and will work better
after with a reindex.

You can have a stable release and a development release (e.g. Xapian 1.0.x and Xapian 1.1.x) installed at the
same time without them interfering with one another, at least for the core library. This may not work so well
for the bindings though.

Mechanics

Once a stable release has settled in, a branch will be created to maintain it with "revision" releases being made as necessary.
Patches and merges from feature branches will be applied to git master first, with changes suitable for the stable release branch being backported from there (so that changes get more testing and to help us keep track). When we decide it's time, we'll start a new development series (by increasing the "minor" version number to be odd). Development releases have so far just been made from trunk, which seems to work pretty well. The development series will gradually get stabilised until it is ready to be declared stable, at which point it will become
the start of the next stable release series.

Increasing the "major" version number will probably be used to indicate particular major changes.

To allow us to concentrate our resources on improving Xapian, we don't plan to support the previous stable release series for long once a new stable release series has been started. If you want longer term support for an old release series (which probably mostly involves back-porting suitable fixes from the new stable release series), you're welcome to volunteer to maintain it, or to hire someone to maintain it for you.

Stable Releases

1.4 Stable Release Series

1.4 is the current stable release series. Changes must not involve incompatible API or ABI changes.

1.4.6 is likely to be released in December 2017.

Version

1.4.0

1.4.1

1.4.2

1.4.3

1.4.4

1.4.5

Released

2016-06-24

2016-10-21

2016-12-26

2017-01-25

2017-04-24

2017-10-16

1.2 Stable Release Series

The 1.2 release series is now retired. We don't plan to make further 1.2.x releases, and recommend users upgrade if they haven't already.

Version

1.2.0

1.2.1

1.2.2

1.2.3

1.2.4

1.2.5

1.2.6

1.2.7

1.2.8

1.2.9

1.2.10

1.2.11

1.2.12

1.2.13

1.2.14

1.2.15

1.2.16

1.2.17

1.2.18

1.2.19

1.2.20

1.2.21

1.2.22

1.2.23

1.2.24

1.2.25

Released

2010-04-28

2010-06-22

2010-06-27

2010-08-24

2010-12-19

2011-04-04

2011-06-12

2011-08-10

2011-12-13

2012-03-09

2012-05-09

2012-06-26

2012-06-27

2013-01-09

2013-03-14

2013-04-16

2013-12-04

2014-01-29

2014-06-22

2014-10-21

2015-03-04

2015-05-20

2015-12-29

2016-03-28

2016-09-16

2017-09-26

1.0 Stable Release Series

The 1.0 release series is now retired. We don't plan to make further 1.0.x releases, and recommend users upgrade if they haven't already.