[Xapian-devel] [Xapian-commits] 10367: trunk/xapian-bindings/ trunk/xapian-bindings/python/

Olly Betts olly at survex.com
Wed Apr 23 10:35:26 BST 2008


On Wed, Apr 23, 2008 at 09:20:48AM +0100, James Aylett wrote:
> On Wed, Apr 23, 2008 at 04:13:22AM +0100, Olly Betts wrote:
> > Or we could just drop 2.2 support in 1.1.0 - perhaps a slightly extreme
> > reaction, but it's close to 5 years since the last Python 2.2 release,
> > and I can't see people conservative enough to still use such an old
> > Python version wanting to install a ".0" release of Xapian anyway, so
> > it's worth considering.
> 
> I'd rather deprecate 2.2 support at 1.1.0 and drop at 1.2.0, if we
> can. (We don't really have a policy for this, but it's in line with
> feature deprecation.)

Our de-facto policy for supporting working with other software is that
we don't aim to actively support versions which are no longer supported
"upstream".  Hence 1.1.0 won't support PHP4 (which we didn't announce
this when we released 1.0.0), and I won't be building packages of it for
Ubuntu edgy, or Debian sarge.  This isn't formally documented mostly
because it just seems to be common sense to me!

Sometimes we can support such versions without extra effort (e.g. Tcl's
stubs mechanism means Tcl 8.1 probably still works, even though the last
release was nearly 9 years ago.  But in most cases keeping support
around is a maintenance overhead (PHP4, GCC 2.95-2.95.2, older Debian
and Ubuntu versions).  And we'd rather spend the time on other things.

Note that there's no guarantee that we will support and continue to
support versions just because upstream still does.  For example, I'm
going to cease Ubuntu dapper packages with 1.1.0 - in this case, it's
because we feel that if you're conservative enough to run dapper, you'd
probably prefer to stick with 1.0.x until you upgrade to hardy (the new
LTS release).  But we may decide not to support versions for other
reasons too.

> Not sure how we communicate it; python has some
> sort of deprecation warning system, I think, or we could just print a
> big banner on configuring xapian-bindings in some way?

I think the appearance of 3 newer Python release series and the lack of
a new 2.2.x release for almost 5 years is enough of a clue really.

The policy for API features is designed to help people migrate
applications painlessly - generally, we want to allow people to write
API-compatible code to support old and new release series with just a
recompile required.  That's not an issue here - writing code which works
on any Python 2.x isn't difficult.

Cheers,
    Olly



More information about the Xapian-devel mailing list