List Info

Thread: Re: 10367: trunk/xapian-bindings/ trunk/xapian-bindings/python/




Re: 10367: trunk/xapian-bindings/ trunk/xapian-bindings/python/
user name
2008-04-23 04:35:26
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

_______________________________________________
Xapian-devel mailing list
Xapian-devellists.xapian.org
http://lists.xapian.org/mailman/listinfo/xapian-devel

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )