Op zondag 13 november 2022 20:08:15 CET schreef john: > > 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.
As far as I know there are only two primary LTS distros: - RHEL - Ubuntu LTS All others are derived from either of these. In the RHEL 7 series, gnucash got stuck on version 2.6.x - I think - due to dependency issues. We moved on, but started to ignore RHEL at that point. In addition it's not really RHEL that carries gnucash. It can only be installed via an add-on repository, EPEL. In Ubuntu, gnucash is in the Ubuntu proper repos. Also contrary to RHEL, Ubuntu LTS has a clear release cadence of two years. For RHEL the time between major releases has been very variable (6 years between 7 and 8, 3 years between 8 and 9, with no commitment to a certain cadence). All reasons it makes it much harder to predict when our dependencies will be updated on RHEL. On the other hand I found today that EPEL 8 ships gnucash 4.9 (https:// packages.fedoraproject.org/pkgs/gnucash/gnucash/epel-8.html[1]). Interestingly I didn't find gnucash for RHEL 9 in EPEL. I haven't followed the evolutions in that area so I don't know any details. That's a lot of ambiguity around a distro to base minimum dependency decisions on. So yes, I meant Ubuntu LTS 22.04 when I wrote that bit. > > > 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. > Just for clarity, you're still talking about our stable series as well, right? In practice this means we indeed may have to introduce #ifdefs if a bleeding edge distro makes API changes that affect our code and that we only can remove them the moment a new Ubuntu LTS release ships. I don't know the exact details of the LTS lifecycle. I know there are intermittent sub releases for the LTS as well (as opposed to the normal Ubuntu releases), but I have no idea which if any library version bumps are allowed in these sub releases. > 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? > I'm not sure I get how these can help us. Can you give an example of when and why to set either parameter ? Regards, _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
