Remove deprecated set_bias() method

[Richard Boulton]

Various methods are wrapped in the bindings with "#ifndef SWIGRUBY", with the comment "We don't wrap methods which were already deprecated when the Ruby bindings were added".

For example, the MSet::get_document_id method is so marked.

These methods should be removed from the bindings for the 1.0 release, along with any other deprecated methods.

If Olly agrees, I'll go through and remove these shortly.

[Olly Betts]

The rationale for never wrapping them for Ruby is that there was no existing Ruby code could be using them.

That may not be true for code in other languages though, and the Ruby bindings were added in 0.9.6 which was released on 2006-05-15 so not being wrapped for Ruby perhaps isn't by itself indication that they've been deprecated for ages.

So I don't know really. The cost of keeping the odd deprecated alias around is fairly small, but we do need to clean them out eventually or we won't be able to see the real code for the cruft!

I think we probably want to decide on a semi-formal policy for deprecating features in such situations. There are a number of old names for Omega CGI parameters, and of course deprecated C++ methods and functions. Perhaps discuss this on the mailing list?

At the most conservative I'd say we can certainly remove anything deprecated in 0.9.0 or earlier, and then make a list for 1.0 of all the remaining already deprecated features with a note that they will be removed in 1.1. We should also probably clearly document what the replacement for any removed deprecated feature is.

[Richard Boulton]

I'm writing a document which describes a policy for deprecating and ultimately removing features, and lists all items currently marked as deprecated (and has a space for listing things which have been removed from the API altogether). I'll commit this to the distribution when I've done with it (with a marker at the top of it saying that it's not yet agreed, and up for discussion, and then kick a message to the mailing list asking for views.

I think most of it will be fairly non-controversial, but I'd like to get it written down before asking on the mailing list to avoid people discussing the easy bits...

I think the most important thing for the future will be to ensure that we give plenty of warning of the impending removal of features, and have clear documentation of what has been removed and what replaces it, so I'm addressing these issues prominently in my document.

[Richard Boulton]

I've still not updated the deprecation document with details of the items in the bindings which are deprecated. This needs to be done before 1.0 is release, but I don't think we should actually remove any interfaces from the bindings, since we've given no warning of their removal. Instead, we should remove anything which we deprecate for 1.0 in version 1.1.

I've managed to work out how to support the existing list-style access to iterator results in python while also supporting a new attribute-style access, which is the main thing I wanted to change, so there is nothing in the interfaces which causes a problem other than untidiness.

[Richard Boulton]

I've now updated the deprecation document such that I think it contains all the items which are slated for deprecation (and also contains full details of the upgrade suggestions).

Having gone through the bindings, there are actually a load of items which have been marked as deprecated for ages, so I've marked these as for removal in 1.0.

The only tricky item is Stem::stem_word(), which is replaced by operator(). I'm not sure if this works in all bindings (though it does in python), so I've marked it as for removal in 1.1.0 instead of 1.0.0. We need to check all the bindings to see if the operator() method is accessible.

Also, MSet::get_document_id() was only deprecated in 0.9.6, so should stay until 1.1.0. I've just added a final deprecation, for ESet::get_termname() - we refer to terms rather than termname everywhere else, so I've added ESet::get_term() for consistency, and deprecated get_termname().

The Perl and Java bindings should be checked for deprecations, but since I don't use either of them, I'm not going to do that... It should be easier to do with the table in deprecation.rst, though.

I'll ask on the mailing list for people to check the list of deprecations, and after a few days we can start actually removing the marked items, in preparation for 1.0.0.

[Olly Betts]

The plan is to redo the Java bindings using SWIG, so I'm currently avoiding wasting effort on housekeeping work on the Java bindings (I'll still fix bugs and apply submitted patches). The move to SWIG is likely to mean some incompatible changes, but even if we decide to strive for complete compatibility, users will want to perform careful testing of their application against the new Java bindings.

Search::Xapian 1.0.0.0 can be released after Xapian 1.0.0, so we needn't do that work right now.

[Olly Betts]

I've now removed all the deprecated xapian-core features marked for removal in 1.0.0. Nobody has spoken up for keeping them, and none of them seem at all controversial.

Not totally sure what to do about Enquire::set_bias() so that's still there for now.

[Richard Boulton]

Olly's removed the deprecated methods from the bindings, too (and I've updated deprecated.rst to show the current state).

So the only outstanding issue as far as I'm concerned is set_bias(). I feel that this should be removed from 1.0 if we are at all likely to be able to implement the replacement within the next couple of months. Which is likely, because I think I'm going to be needing it (and we've got a good start made on it already) ... ;-)

[Olly Betts]

I've now removed set_bias(), plus stuff in Omega and the bindings which relies on it.

[Olly Betts]

Fixed in 1.0.0 release.