Making a release of Xapian

This is a (hopefully complete) list of the jobs which need doing:

  • If there are changes which are likely to affect the RPM packaging, email Fabrice Colin and Tim Brody so they can check it.

  • Check if config/config.guess and config/config.sub need updating to more recent versions from

  • Check the revision currently specified in the bootstrap for the common subdirectory. Unless there’s a good reason, we should release xapian-core and omega with synchronised versions of the shared files.

  • Make sure that any new/changed/removed API methods in xapian-core have been wrapped/updated/removed in xapian-bindings.

  • Update the lists of deprecated/removed API methods in docs/deprecation.rst

  • Update the NEWS files using information from the git logs

  • Update the version in for each module (xapian-core, omega, and xapian-bindings), and the library version info in xapian-core’s

  • Make sure the submitters of fixed bugs are mentioned in the “thanks” list in xapian-core/AUTHORS. Check the list for the appropriate milestone:
  • Check for any unfixed bugs on the milestone for the new release, and if they aren’t blockers, retarget them:
  • Tag the source trees for the new revision - use the git-tag-release script, running it with the new version number, for example:

    xapian-maintainer-tools/git-tag-release 1.4.12

    This script also generates tarballs for the new release and copies them across to the website.

  • Update the wiki:

    Fill in

    If the next release isn’t likely to be in 2 months time, update the roadmap at with a revised estimated date.

  • Update the website: generate in the git repo contains the latest version and the date it was released.

  • Run ./update_website in the cloned repo on the webserver.

  • Announce the new version on xapian-discuss

  • Update the version numbers in this checklist ready for the next release

  • Have a nice cup of tea!

How to make Debian packages for a new release

Debian control files are stored in separate git repositories:

To package a new upstream release, these should be updated as follows:

  • If there are any patch files in “debian/patches”, check if these have been incorporated into the new release, and if so remove them and update “debian/patches/series”.

  • Update the debian/changelog file, being sure to keep it in the standard Debian format (the easiest way is to use the dch utility like so: dch -v 1.2.19-1. The new version number should be the version number of the release followed by “-1” (i.e., a debian patch number of 1). The changelog message should indicate that there is a new upstream release, and should mention any significant changes in the new release.

  • Tag using: git tag -s -m 1.2.19-1 1.2.19-1

  • FIXME: Document how to make source packages, or update make-source-packages.

  • FIXME: Document how to build binary packages, or update build-packages.

  • Test the packages.

  • Run debsign build/*_amd64.changes to GPG sign the packages.

  • Run dput build/*_amd64.changes to upload them to Debian.

  • For the Ubuntu backports:

    ./backport-source-packages xapian-core 1.2.19-1 ubuntu
    ./backport-source-packages xapian-omega 1.2.19-1 ubuntu
    ./backport-source-packages xapian-bindings 1.2.19-1 ubuntu

    And once libsearch-xapian-perl is uploaded to Debian unstable:

    ./backport-source-packages libsearch-xapian-perl ubuntu

    Then sign:

    debsign build/*99*_source.changes


    dput xapian-backports build/xapian-core*99*_source.changes

    Wait for that to have a chance to build, and then:

    dput xapian-backports build/xapian-[bo]*99*_source.changes
    dput xapian-backports build/libsearch-xapian-perl*_source.changes