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
Olly Betts <olly at survex.com> wrote:> 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)Just wondering if there's docs on what improvements users can expect from honey. Mainly smaller size? I'm pretty happy with glass :> But I still use SQLite for big, "all results" type sorts.> 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.Wow, that's honey even w/o update support? I can't fathom rewriting a large DB multiple times a day. Anyways, thanks again for Xapian!
It's high time for a progress update. On Mon, Mar 06, 2023 at 04:46:53AM +0000, Olly Betts wrote:> 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.This is the current plan still. We're not there yet, but we are down to 7 open trac tickets on the 1.5.0 milestone, and several of those are actually partly done. I don't have a target release date yet, but if you've been working on something and hope it'll be merged before the new release, please open an issue or MR or start a discussion on the list very soon or it'll have to wait (if it's API and ABI compatible it can be merged after we've started the new release series; otherwise it will have to be merged to git master and wait for the following release series).> In numbering terms, I suggest we'd start 1.6.x soon, then probably make > the MPL release series 2.0.x.Perhaps we should adopt "semantic versioning" (https://semver.org/)? If we're going to, the start of a new release series is the sensible time to. Smever has always seemed slightly flawed to me, but then most versioning schemes are because the real world is a complicated place, and semver is at least widely known at this point, and many projects manage to use it in practice. That would make the next release series 2.x.y and the one after 3.x.y. Most of our stable releases aren't purely bug fixes, so we'd probably end up with 2.0.0, 2.1.0, 2.2.0, etc and not using the patch part of the version much. We could batch up changes which aren't bug fixes and merge them less frequently, but we haven't had feedback suggesting users are unhappy with our current approach.> 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!Nobody spoke up as wanting development releases, so I'm not intending to make them any more. Instead I would encourage everyone to start testing with git master if you haven't already, and to report any problems you find. The intention is that (aside from features which were marked as deprecated before 1.4.0 and have now been removed) that code using Xapian 1.4 should continue to build and work with the next release series. Once we're very close to the release I'll make a release candidate (and repeat if problems are found). Cheers, Olly