The current plan for the next release series includes relicensing
the C++ libxapian library in xapian-core as MPL. The remaining
blockers for this are:
* adding update support to the new honey backend (to replace glass)
* adding support for RAM storage to honey (to replace inmemory)
* moving some remote client and server code out of libxapian (or
replacing it)
I'm certainly still aiming to get these done, but it's occurred to me
that we could start a new release series now-ish which is still GPL,
then start a new release series with the licensing changes once the
above are complete.
I think this would be approximately the same amount of total work as
sticking with 1.4.x (there's some extra work to starting a new release
series, but some work saved because backporting fixes becomes simpler
than currently - RELEASE/1.4 branched in 2016 and a lot of code has
changed completely on master since), but delivers the many useful
changes currently only on git master to users sooner.
I know at least one major user of Xapian has been using builds based
on git master for several years so it's already seen real-world use.
In numbering terms, I suggest we'd start 1.6.x soon, then probably make
the MPL release series 2.0.x.
1.4.x would move to a "minimise work" state - we'd aim to fix
security
and data-loss bugs, and maybe portability and the like if the changes
aren't invasive.
Currently master requires C++17 to build xapian, which seems a
reasonable requirement for a new stable release series in 2023.
In 1.4.x we require C++11 to build xapian but aim to allow the API
headers to be used from other software without enabling C++11 (because
it wasn't on by default in most C++ compilers when we branched). C++
compilers now typically default to a fairly recent C++ standards
version, and C++ codebases increasingly seem to require it anyway, so I
think we could reasonably require C++17 in the API headers too which
would make things simpler.
Previously we've made development releases (e.g. 1.3.0, 1.3.1, ...
before 1.4.0) to try to make it easier for people wanting to help test
before the release. My impression is people are more willing to pull
code from git and built it these days (and we've streamlined the process
of bootstrapping the source tree) so I wonder if these are still
actually useful. It's a waste of effort making them if nobody is going
to use them!
Seeking thoughts on any/all of the above.
Cheers,
Olly