Release plans

[Olly Betts]

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