[GNC-dev] Dependencies policy for major releases

[john]

We're getting close to starting the beta testing cycle for GnuCash 5.0. Part of the preparations is deciding the minimum versions to set for dependencies; those minimum versions influence what features we can support and code complexity. For example, we merged a patch last year to enable SEPA internal transfers using AQBanking. It requires a feature introduced in AQBanking 6.4.0, so of GnuCash to be buildable with older versions of AQBanking the build has to detect the AQBanking version and either compile or not compile the code that implements the feature.

When I started working on GnuCash 13 years ago the policy was that minimum dependency versions were what was provided by the current RHEL release. Some time around 10 years ago we noticed that RHEL had stopped including not just GnuCash but several of our dependencies and was falling behind on significant updates. Within a couple of years Red Hat created Fedora with a 6-month release cycle and Canonical started up and began releasing Ubuntu with a similar 6-month release cycle. Gtk had a major release, Gtk3, with some pretty substantial API changes. WebKitGtk, which we use to render reports, stopped supporting Gtk2. We ignored all of that until 2017 when an OpenSuSE packager informed us--6 months before we were to release GnuCash 2.8--that they weren't going to package WebKitGtk 2.10, the last version that supported Gtk2, and that if we didn't update our dependency we wouldn't be in the next distribution. Red Hat soon warned us that  would be true for the next release of Fedora too. Geert started a crash Gtk3 migration and I migrated WebKitGtk. The current RHEL still didn't support Gtk3, so we clearly needed a new dependency version benchmark. We settled on the 1 version old Ubuntu LTS release, 14.04. We did the same for 4.0, basing our dependency minimum versions on Ubuntu 18.04.

What about Windows and macOS? On Windows we use MSYS2/MinGW-w64 and they, like Arch Linux, always have the latest stable releases of everything they supply and we build the rest. On macOS we build the entire stack from source and can similarly use recent stable releases. Minimum dependency versions are of concern only on Linux.

Our Ubuntu policy would have us set the dependencies based on Ubuntu 20.04 LTS, but that has only AQBanking 6.0.1 and we'd like to make the minimum 6.4 so that we can remove the conditional compilation mentioned in the first paragraph.

There's been another major change in the Linux ecosystem: Flatpak. It's always reasonably up to date, it's distribution agnostic, and it enables us to package GnuCash for immediate consumption: We even have nightly builds of both the stable and development branches. For those who prefer to build their own versions of GnuCash flatpak also affords an up to date build environment regardless of what's provided by the installed distribution.

The most extreme policy would be that the minimum dependency level for any release, even a minor one, is that we code to the dependency's current stable release without any conditional compilation and set the minimum requirement to whatever we use from that dependency. Sticking with AQBanking, the current stable release is 6.5, but we don't use any 6.5 API; we do use functions introduced in 6.4 so that would be the minimum version. If the AQBanking developers add new API that we want or need (thinking of the FinTS change in 2020) in say, summer 2024, then the minimum version for the subsequent release (5.13 if we get 5.0 out next March) would be the stable release providing that new API. A more conservative position would freeze the minimum version at 6.4 for the duration of the 5.x series so that the new code would have to be conditionally compiled in the maintenance branch until it gets replaced with the release of GnuCash 6.0.

What really makes sense? How many users are building for themselves and on what?

Regards,
John Ralls