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 https://git.savannah.gnu.org/gitweb/?p=config.git
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 configure.ac for each module (xapian-core, omega, and xapian-bindings), and the library version info in xapian-core’s configure.ac
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:
This script also generates tarballs for the new release and copies them across to the website.
Update the wiki:
If the next release isn’t likely to be in 2 months time, update the roadmap at https://trac.xapian.org/wiki/RoadMap with a revised estimated date.
Update the website:
www.xapian.orggit repo contains the latest version and the date it was released.
./update_websitein 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”.
debian/changelogfile, 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.
git tag -s -m 1.2.19-1 1.2.19-1
FIXME: Document how to make source packages, or update
FIXME: Document how to build binary packages, or update
Test the packages.
debsign build/*_amd64.changesto GPG sign the packages.
dput build/*_amd64.changesto 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 220.127.116.11-1 ubuntu
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