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 not explicitly time driven, but we aim to make a release every one to two months. Between releases development work is performed on the trunk of the SVN tree.

Releases are given three-part version numbers (e.g. 1.0.2), the three parts being termed "major" (1), "minor" (0), and "revision" (2). Generally, xapian-core, omega, and xapian-bindings will be released together with the same version number. Occasionally the bindings may be released independently with a 4 part version number.

Stable Releases

Releases which only increase the "revision" number are intended as stable releases and should not break API or ABI from the previous release. However, 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).

Releases which increase the "minor" or "major" revision 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 we'll start a new release series (by increasing the "minor" revision number) roughly once a year. Increasing the "major" revision number will probably be used to indicate particular major changes. Otherwise there's no real difference between a change in "minor" or "major" revision number.

Towards the end of a release cycle a branch will usually be created to maintain the current release series, and make "revision" releases as necessary. The trunk will then accept changes which break API or ABI compatibility in preparation for the next "major" or "minor" release.

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

Development Releases

Starting with Xapian 1.1.x, we're trying a new scheme - a 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.

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.

It should be possible to have Xapian 1.0.x and Xapian 1.1.x installed at the same time. Using a different prefix will allow this, and is probably the simplest approach.

Milestones

Version 1.0.0

This was released on 2007-05-17.

Version 1.0.1

This was released on 2007-06-11.

Version 1.0.2

This was released on 2007-07-05.

Version 1.0.3

This was released on 2007-09-28.

Version 1.0.4

This was released on 2007-10-30.

Version 1.0.5

This was released on 2007-12-21.

Version 1.0.6

This was released on 2008-03-17.

Version 1.0.7

This was released on 2008-07-15.

Version 1.0.8

This was released on 2008-09-04.

Version 1.0.9

This was released on 2008-10-31.

Version 1.0.10

milestone:1.0.10 tracks issues we want to address in this release.

The 1.0.x branch 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.

There's no fixed release date for 1.0.10, but perhaps expect something in early December.

Version 1.1.0

We started work on the 1.1.0 release early in 2008 and aim to release it early in 2009.

The 1.1.x series will be 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.0 is being used to collect likely features, but some major planned changes are:

  • Merge the "clustering" branch which provides functionality allowing clustering of documents according to a similarity measure.
  • Merge the "matchspy" branch which provides functionality allowing categorisation of search results.
  • Merge the "opsynonym" branch which implements an OP_SYNONYM query operator. This acts like OP_OR except that the weights are calculated on the assumption that the terms being combined are synonyms for each other.

Possible additional goals:

  • Migrate Java bindings from hand-coded JNI to SWIG.
  • Bring the Perl bindings fully up-to-date. This could happen in any release, but perhaps the best way to do this it to convert them to use SWIG which might mean a few incompatible changes. We'd need to fix SWIG/Perl to support directors first though (update: someone is now working on this for SWIG).

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").
  • We will stop supplying backported packages for Debian sarge in the repo on xapian.org (Debian themselves ended security support for sarge on 2007-03-31). The last 1.0.x packages for sarge were of 1.0.5.
  • We will stop supplying backported packages for Ubuntu edgy (6.10) in the repo on xapian.org (Ubuntu themselves ended security support for edgy on 2008-04-26). The last 1.0.x packages for edgy were of 1.0.5.
  • We will stop supplying backported packages for Ubuntu feisty (7.04) in the repo on xapian.org (Ubuntu themselves ended security support for feisty on 2008-10-19). The last 1.0.x packages for feisty were of 1.0.7.
  • We will stop supplying backported packages for Ubuntu dapper (6.06) in the repo on xapian.org. 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.