> On Nov 13, 2022, at 6:28 AM, Geert Janssens <geert.gnuc...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
