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.
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.
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
milestone:1.0.9 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 HEAD for 1.1.x.
There's no fixed release date for 1.0.9 (it's even possible, though unlikely, that there might not be such a release), but perhaps expect something in October.
Version 1.1.0
We started work on the 1.1.0 release early in 2008 and aim to releasing it when it's ready.
The original plan was for 1.1.x to be a stable release branch in a similar way to 1.0.x, but there are a lot of changes we'd like to merge so we're considering whether to make 1.1.x a development release series leading to a stable 1.2.x release series. Users can then chose 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.
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 (upstream 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 plan to end security support for feisty on 2008-10-??).
- We will stop supplying backported packages for Ubuntu dapper (6.06) in the repo on xapian.org. Although Ubuntu themselves plan to support dapper for some time to come, 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.
