Re: [GNC-dev] Dependencies policy for major releases
Op zondag 13 november 2022 20:08:15 CET schreef john: > > On Nov 13, 2022, at 6:28 AM, Geert Janssens > > 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
Re: [GNC-dev] Dependencies policy for major releases
> On Nov 13, 2022, at 6:28 AM, Geert Janssens > 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
Re: [GNC-dev] Dependencies policy for major releases
Op zaterdag 29 oktober 2022 18:53:57 CET schreef john: > What really makes sense? How many users are building for themselves and on > what? Here are a few of my thoughts on this topic (I threw away several earlier attempts because they became way too long...) With my developer hat on I prefer to have as little conditional code as possible in the sources as this complicates reasoning about the code and makes it harder to test. So ideally no parts of the code that require certain versions of a dependency and other parts of the code for other versions of that same dependency. So that's the "most extreme" policy in John's writing. I am aware this is not always possible, especially as we offer gnucash on multiple platforms. 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. >From the perspective of an end user (on linux), the group affected the most >are self-builders. A few have spoken up, but I have no idea of the size of this group in the wider community and whether or not they tend to run up-to-date distros. The feedback we have received so far expresses a prudent willingness to self-build dependencies if needed. On the whole my opinion is we can aim for more recent dependencies when it's useful, needed or desired. 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. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
Not a Dev, but I build each release on MX-21 - Debian 11 based. I sometimes have needed to satisfy a dependency but that has helped educationally. Thanks to Devs for their great efforts. Mike C On Sat, Oct 29, 2022 at 6:45 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > Mint 21 is based on Ubuntu 22.04, so it seems there shouldn't be any > serious concerns right off. > > Regards, > Adrien > > On 10/29/22 7:08 PM, John Ralls wrote: > > I don't know how to support that: https://repology.org doesn't report > linux mint 21 at all and 20 shows only 137 packages, with no entries for > aqbanking, anything starting with lib including libgtk+-3.0, libofx, or > libxml, nor sqlite3. Searching for those names at > http://packages.linuxmint.com also produced nothing. However, > https://en.wikipedia.org/wiki/Linux_Mint says that Mint follows Ubuntu > LTS releases with a slight delay. As long as that's true and you keep up to > date with new releases you should have no problems. > > > > Regards, > > John Ralls > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
Mint 21 is based on Ubuntu 22.04, so it seems there shouldn't be any serious concerns right off. Regards, Adrien On 10/29/22 7:08 PM, John Ralls wrote: I don't know how to support that: https://repology.org doesn't report linux mint 21 at all and 20 shows only 137 packages, with no entries for aqbanking, anything starting with lib including libgtk+-3.0, libofx, or libxml, nor sqlite3. Searching for those names at http://packages.linuxmint.com also produced nothing. However, https://en.wikipedia.org/wiki/Linux_Mint says that Mint follows Ubuntu LTS releases with a slight delay. As long as that's true and you keep up to date with new releases you should have no problems. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
> On Oct 29, 2022, at 2:40 PM, David Cousens wrote: > > John, > I usually build the latest release from the source code on Linux Mint > (currently > 21.3) as soon as a new release comes out. My desktop is getting a bit ancient > but still has no problem with Linux. I also run the Windows version on my > wife's > laptop (Windows 11). Not averse to having to build dependencies from scratch > on > Linux if I have to but would prefer not to where possible. > I tried Flatpak early on when there was a bit of extra setup to configure > access > to the system resources but haven't been back now that most of those have > likely > been sorted. David, I don't know how to support that: https://repology.org doesn't report linux mint 21 at all and 20 shows only 137 packages, with no entries for aqbanking, anything starting with lib including libgtk+-3.0, libofx, or libxml, nor sqlite3. Searching for those names at http://packages.linuxmint.com also produced nothing. However, https://en.wikipedia.org/wiki/Linux_Mint says that Mint follows Ubuntu LTS releases with a slight delay. As long as that's true and you keep up to date with new releases you should have no problems. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
John, I usually build the latest release from the source code on Linux Mint (currently 21.3) as soon as a new release comes out. My desktop is getting a bit ancient but still has no problem with Linux. I also run the Windows version on my wife's laptop (Windows 11). Not averse to having to build dependencies from scratch on Linux if I have to but would prefer not to where possible. I tried Flatpak early on when there was a bit of extra setup to configure access to the system resources but haven't been back now that most of those have likely been sorted. David Cousens ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
Good afternoon, On Sat, Oct 29, 2022 at 9:54 AM john wrote: [...] > What really makes sense? How many users are building for themselves and on > what? > No idea what makes sense for dependencies, I recently started building for myself on Debian 11, but I can and am willing to work out dependency issues. -- Glenn S. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Dependencies policy for major releases
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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
