[GNC-dev] Dependencies policy for major releases

[john]

> On Nov 13, 2022, at 6:28 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> How recent then can "more recent" be ? In my mind anything that's in the most recent LTS, should be fine in all cases. For anything more recent than that, we should consider how hard it would be to self-build the dependency.
> 

For clarity, I think you mean Ubuntu's latest LTS, currently 22.04.

> The other approach, where we freeze minimum dependencies on the stable branch, sounds like a nice compromise, but has the drawback that it makes the stable code more complicated in order to accommodate support for multiple versions of a dependency. So we trade the stability of an older dependency for complexity in our own code. I don't know if that's really a good trade-off for a small development team.

I think that means that we'd bump a dependency's minimum version only in the case where there's an API change that would otherwise require that we have to #ifdef on the dependency version--or rather that bumping the minimum version lets us remove ifdefs introduced to keep building on both the current Ubuntu LTS and bleeding-edge distros like Arch Linux and Debian Unstable. 

Then there's Gnome and macOS which have very nice versioning macros and deprecation policies that let you tune what the compiler will warn about. See e.g. https://docs.gtk.org/glib/const.VERSION_MIN_REQUIRED.html. There's a corresponding GLIB_VERSION_MAX_ALLOWED that somehow eluded gi-doc, see glib/versionmacros.h.in. There are corresponding macros for Gtk and Gdk. The idea is that MIN_REQUIRED will emit deprecation warnings for API deprecated in that version or earlier while MAX_ALLOWED will warn if you use API that was introduced after that version. Should we start using these to try to keep our code more current? (I think so.) If so how should we set them?

Regards,
John Ralls