Roadmap

This page describes the current expected direction of future development of Xapian. Nothing in this roadmap is guaranteed, and time-scales are completely estimated.

Release Policy

Releases are given three-part version numbers (e.g. 1.0.2), the three parts being termed "major" (1), "minor" (0), and "revision" (2). Releases with the same major and minor version are termed a "release series".

For Xapian releases 1.0.0 and higher, an even minor version indicates a stable release series, while an odd minor version indicates a development release series.

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 about a year between stable release series.

Development Releases

Xapian 1.1.x is our first development release series. The idea is that this 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. This is essentially an experiment - do let us know how well it seems to work for you. To try to avoid confusion, if we decide not to have another development release series (either ever, or occasionally) we will skip the odd minor number.

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. if Unicode 5.2 is released while we are still working on 1.1.x, we may update to it). 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 Xapian 1.0.x and Xapian 1.1.x installed at the same time without them interfering with one another.

Mechanics

Once a stable release has settled in, a branch will be created to maintain it with "revision" releases being made as necessary. Changes will go on to SVN trunk 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 will probably just be made from trunk, but we'll have to see how that works out. 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.

1.0 Stable Release Series

For dates of releases prior to 1.0.0, see branches/0.9/xapian-core/NEWS.

The 1.0 release series is now in maintenance mode. Essentially, bug-fixes only, and nothing too invasive. New features are unlikely to be incorporated but should instead go into SVN trunk for 1.1.x.

Version	1.0.0	1.0.1	1.0.2	1.0.3	1.0.4	1.0.5	1.0.6	1.0.7	1.0.8	1.0.9	1.0.10	1.0.11	1.0.12	1.0.13
Released	2007-05-17	2007-06-11	2007-07-05	2007-09-28	2007-10-30	2007-12-21	2008-03-17	2008-07-15	2008-09-04	2008-10-31	2008-12-23	2009-03-15	2009-04-19	2009-05-23

There's no fixed release date for 1.0.14, but perhaps expect something in early July 2009. milestone:1.0.14 tracks issues we want to address in this release.

1.1 Development Release Series

Version	1.1.0	1.1.1
Released	2009-04-22	2009-06-09

The 1.1.x series is a "development" release series (leading to a stable 1.2.x release series, hopefully after a few months). We're doing this as we have a lot of changes we'd like to merge, but the code is in good shape and we'd like to provide users with an easy way to try out some of the nifty improvements and new features.

1.0.x will continue to tick along, so users can choose if they prefer to use 1.0.x for ultra-stability or 1.1.x for exciting shiny features.

milestone:1.1.2 milestone:1.1.3 milestone:1.1.4 and milestone:1.1.7 are being used to collect features we hope to include at approximate points in this release series.

Already done:

• Features which were deprecated in version 1.0.0 or earlier have been removed. Notably, this includes the quartz backend.
• Support for PHP4 has been dropped (the PHP developers regard it as totally dead as of 2008-08-08).
• Stop storing the document lengths in every postlist, in a new development backend (called "chert").
• New PostingSource class allowing external information sources to be used during the match process.
• Stop supplying backported packages for Debian sarge (Debian themselves ended security support for sarge on 2007-03-31). The last 1.0.x packages for sarge were of 1.0.5.
• Stop supplying backported packages for Ubuntu edgy (6.10) (Ubuntu themselves ended security support for edgy on 2008-04-26). The last 1.0.x packages for edgy were of 1.0.5.
• Stop supplying backported packages for Ubuntu feisty (7.04) (Ubuntu themselves ended security support for feisty on 2008-10-19). The last 1.0.x packages for feisty were of 1.0.7.
• Stop supplying backported packages for Ubuntu gutsy (7.10) (Ubuntu themselves ended security support for gutsy on 2009-04-18). The last 1.0.x packages for gutsy were of 1.0.7.
• Stop supplying backported packages for Ubuntu dapper (6.06). Although Ubuntu themselves plan to support dapper until June 2011 on servers, the Ubuntu LTS releases are aimed at conservative users favouring stability over having the latest versions. Therefore it seems appropriate to end dapper support with the move to Xapian 1.1.0.