Hi folks,
We're getting pretty close to Xapian 2.0.0 now. Currently there are two
open tickets, but at least one may just get deferred. I'm currently
expecting to get a release candidate out in early February.
I'd like to encourage people to test current Xapian git master with
their applications. Supporting both 1.4.x and 2.0.x in applications
should be easy. The general intention is that code which works with
Xapian 1.4.x should work with Xapian 2.0.0 except for features marked as
deprecated since 1.4.0 or earlier. However it would be good to have
wider real-world testing to shake out any problems. It may be hard to
fix unintended incompatibilties after the release as then we're
restricted to not breaking the ABI.
Also useful would be testing on more platforms. We have fairly broad
CI coverage, but it doesn't include every platform we've had reports
of people using, and only tests one version of most platforms:
https://github.com/xapian/xapian/actions
The fairly limited testing I've done myself has uncovered one area where
code may not just work, because the Xapian C++ API now takes
`std::string_view` parameters in many places instead of `const
std::string&` or `std::string`. If you pass in a class which provides
a conversion operator to `std::string` then the compiler is not allowed
to chain implicit conversions so it may not be able to convert it to
`std::string_view`. To support this in the Xapian 2.0.0 API I think
we'd have to provide (inlined) overloaded versions of every method
taking `std::string_view` which take `const std::string&` instead, so
given this seems a corner case I'd expect to be rare in practice I think
the best resolution is to adjust user code to add a conversion to
`std::string_view` to such classes (if you keep the existing conversion
to `std::string` the code should then work for 1.4.x and 2.0.0).
A related case I saw was `Xapian::sortable_serialise(NULL)` which
gives a compiler error with 2.0.0; with 1.4.x it compiles but invokes
undefined behaviour if the call actually happens, so I think it's
actually better that it no longer compiles. This invalid call was
seen in error handling code where it was used as a default return
value in case of parameter validation failing. The most appropriate
fix here seems to be to return a hard-coded double constant such
as `0.0` or `HUGE_VAL`.
If you find a case which works with 1.4.x and doesn't with 2.0.x other
than one of these, please raise it (either here or in trac).
By default, git master installs scripts and tools with a `-1.5` suffix
and the library as e.g. `libxapian1.5.so` which means they can be
easily installed in parallel with Xapian 1.4.x. 2.0.x won't have
this these suffixes by default; if you want to test something more
like 2.0.x, you can turn off suffixing of programs with:
./configure --program-suffix
There isn't currently an easy way to turn off the library suffixing for
testing.
Cheers,
Olly