Xapian devel - May 2007 - Xapian::xapian_version_string(), etc

I noticed this footnote in deprecation.rst:

    .. [#version] The version functions will probably be preserved for
    longer than the usual lifetime of deprecated features, because it is
    unhelpful to remove functions which people use to test the version
    of the library in use.  However, the replacements have been
    supported for long enough that new applications should use the
    replacement functions without worrying about old library versions
    which don't support them.

I don't think there's a reason to support these for longer than we might
otherwise actually.  These functions report the version of xapian-core
that we're running with (which may be different from the version that
we were built against if xapian-core is a shared library).  But you can
only use an API compatible shared library, otherwise you need to
rebuild, so you generally you'd use preprocessor checks for compile time
selection of things.

You can also use preprocessor checks to decide which function name to
call if you really need to check the library version actually in use.
These functions were added in 0.9.3, and deprecated in favour of names
with "xapian_" removed in 0.9.6, so this code will work for any Xapian
version from 0.9.3 onwards:

#if XAPIAN_MAJOR_VERSION == 0 && XAPIAN_MINOR_VERSION == 9 &&
XAPIAN_REVISION < 6
    string version_string = Xapian::xapian_version_string();
#else
    string version_string = Xapian::version_string();
#endif

So I don't think there's a reason to keep these around longer than we
would otherwise.  I think removing these in 1.1.0 would be fine, and we
should suggest otherwise in the documentation.  Am I missing something?

Cheers,
    Olly

On Tue, May 08, 2007 at 12:55:40AM +0100, Olly Betts
wrote:
> So I don't think there's a reason to keep these around longer than
we
> would otherwise.  I think removing these in 1.1.0 would be fine, and we
> should suggest otherwise in the documentation.  Am I missing something?
I'm missing a not:

[...] we should NOT suggest otherwise in the documentation!

Cheers,
    Olly

Olly Betts wrote:
> So I don't think there's a reason to keep these around longer than
we
> would otherwise.  I think removing these in 1.1.0 would be fine, and we
> should suggest otherwise in the documentation.  Am I missing something?
No, I think your points were all valid.  I've just been thinking in 
Python terms too much recently, where API compatibility is a much more 
flexible thing.  But even in python, you could detect an out-of-date 
xapian by catching the AttributeError when you try and call the version 
function, so there's no need to keep the old functions around indefinitely.

I've removed the comment from deprecation.rst, and I noticed that I 
missed the xapian_version functions from the list of deprecated 
functions in the bindings, so I've added them to that.

-- 
Richard