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
