How old a version of xapian should notmuch support?

[David Bremner]

I'm looking at changes to get notmuch running with xapian-1.5
(developement version). One thing that has changed is the compact API we
are using (deprecated since 1.3.4, Jan 2016) has been dropped
[1]. Updating to the new version is easy enough, but maintaining support
for two versions is a bit boring.

One option is to bump the version of xapian required to run the next
release of notmuch. We could bump to 1.3.4, but since it's a development
version, for many users (e.g. on Debian) that means 1.4.0, which is
roughly two years old now.

From a Debian-centric point of view, now is about the right time to drop
support for the 1.2.x series of xapian; it's most recently available in
Debian Wheezy, for which the Debian long term support initiative will
end support at the end of this month (May 2018).

On the other hand, not everyone uses Debian. Travis is one place that
would require some work to get working (they're still using the _last_
LTS version of Ubuntu).

We can of course continue to support 1.2.x. It will increase the level
of ifdefication, especially if/when we try to support xapian-1.5+.

So how many people are actually using libxapian22? [2]


[1] I expect a few other changes will be needed to get notmuch working
properly with xapian 1.5; currently 11 tests fail.

[2] You can test via "ldd $(which notmuch) | grep xapian". If that says
libxapian.so.30, you are using current xapian, and can ignore this
discussion.

[Tomi Ollila]

Post by David Bremner
I'm looking at changes to get notmuch running with xapian-1.5
(developement version). One thing that has changed is the compact API we
are using (deprecated since 1.3.4, Jan 2016) has been dropped
[1]. Updating to the new version is easy enough, but maintaining support
for two versions is a bit boring.
One option is to bump the version of xapian required to run the next
release of notmuch. We could bump to 1.3.4, but since it's a development
version, for many users (e.g. on Debian) that means 1.4.0, which is
roughly two years old now.
From a Debian-centric point of view, now is about the right time to drop
support for the 1.2.x series of xapian; it's most recently available in
Debian Wheezy, for which the Debian long term support initiative will
end support at the end of this month (May 2018).
On the other hand, not everyone uses Debian. Travis is one place that
would require some work to get working (they're still using the _last_
LTS version of Ubuntu).
We can of course continue to support 1.2.x. It will increase the level
of ifdefication, especially if/when we try to support xapian-1.5+.
So how many people are actually using libxapian22? [2]
[1] I expect a few other changes will be needed to get notmuch working
properly with xapian 1.5; currently 11 tests fail.
[2] You can test via "ldd $(which notmuch) | grep xapian". If that says

cli(1)$ ldd =notmuch vc/ext/notmuch
käynnistettävää tiedostoa ei voi ladata dynaamisesti
zsh: exit 1 ldd =notmuch
cli(1)$

that said, I know I'm using 1.2.24, but I think I have no difficulty to
update to 1.4 series, I've just been lazy to do so.

Tomi

Post by David Bremner
libxapian.so.30, you are using current xapian, and can ignore this
discussion.
_______________________________________________
notmuch mailing list
https://notmuchmail.org/mailman/listinfo/notmuch

[David Bremner]

Post by David Bremner
I'm looking at changes to get notmuch running with xapian-1.5
(developement version). One thing that has changed is the compact API we
are using (deprecated since 1.3.4, Jan 2016) has been dropped
[1]. Updating to the new version is easy enough, but maintaining support
for two versions is a bit boring.
One option is to bump the version of xapian required to run the next
release of notmuch. We could bump to 1.3.4, but since it's a development
version, for many users (e.g. on Debian) that means 1.4.0, which is
roughly two years old now.

It occurred to me that such a change would also allow a simplification
of the documentation and code by making FieldProcessors mandatory. This
means that several query language features would stop being optional.

d

[David Bremner]

Post by David Bremner

Post by David Bremner
I'm looking at changes to get notmuch running with xapian-1.5
(developement version). One thing that has changed is the compact API we
are using (deprecated since 1.3.4, Jan 2016) has been dropped
[1]. Updating to the new version is easy enough, but maintaining support
for two versions is a bit boring.
One option is to bump the version of xapian required to run the next
release of notmuch. We could bump to 1.3.4, but since it's a development
version, for many users (e.g. on Debian) that means 1.4.0, which is
roughly two years old now.

It occurred to me that such a change would also allow a simplification
of the documentation and code by making FieldProcessors mandatory. This
means that several query language features would stop being optional.

I have have sent a patch deprecating pre 1.4.0 xapian. Unless
convinced otherwise, I'll apply that for 0.27.

d

[Antoine Beaupre]

Post by David Bremner
I'm looking at changes to get notmuch running with xapian-1.5
On the other hand, not everyone uses Debian. Travis is one place that
would require some work to get working (they're still using the _last_
LTS version of Ubuntu).

I find it quite ironic that the "devops" kids who are so critical of
Debian being so "old" base much of their infrastructure on a service
that is running what is basically an old derivative of Debian wheezy,
released in 2013 (Trusty LTS was released in 2014).

There are other and better CI systems out there, in case Notmuch is
stuck in Travis-land. I have had good experiences working with GitLab CI
which is based on a slightly saner approach: it uses Docker containers
as a base, so you can run any base system you want. You can also supply
your own physical machines as runners for the CI system if you're not
happy with the provided options.

All this to say I don't think that Notmuch should block on Trusty
LTS. It will die in about 8 months anyways (april 2019) so it's a good
time to get rid of that cruft.

Besides, Ubuntu is shipping its own notmuch packages of course, and
trusty is stuck back there in 0.17.

HTH,

A.

[David Bremner]

Post by Antoine Beaupre
There are other and better CI systems out there, in case Notmuch is
stuck in Travis-land. I have had good experiences working with GitLab CI
which is based on a slightly saner approach: it uses Docker containers
as a base, so you can run any base system you want. You can also supply
your own physical machines as runners for the CI system if you're not
happy with the provided options.

Well, we had a buildbot installation, which was nice enough, but the
volunteer who ran it moved on to other things. Travis mainly has the
advantage that I don't have to maintain it. Well, except for patching
notmuch to work on it, which hasn't been too heinous so far.

d

[Antoine Beaupré]

Post by David Bremner

Post by Antoine Beaupre
There are other and better CI systems out there, in case Notmuch is
stuck in Travis-land. I have had good experiences working with GitLab CI
which is based on a slightly saner approach: it uses Docker containers
as a base, so you can run any base system you want. You can also supply
your own physical machines as runners for the CI system if you're not
happy with the provided options.

Well, we had a buildbot installation, which was nice enough, but the
volunteer who ran it moved on to other things. Travis mainly has the
advantage that I don't have to maintain it. Well, except for patching
notmuch to work on it, which hasn't been too heinous so far.

Well, GitLab CI runs on its own as well. You don't *have* to provide a
runner. :)

A.