Support for older distros

[John Ralls]

> On Mar 23, 2017, at 8:56 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On donderdag 23 maart 2017 15:52:52 CET John Ralls wrote:
>>> On Mar 23, 2017, at 3:49 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
>>> wrote:> 
>>> On woensdag 22 maart 2017 22:05:25 CET Geert Janssens wrote:
>>>> commit 9f3ad5510427eb69c857814de15e1c1be0727d2d
>>>> Author: Jesse Olmer <jesse at wickedgoodtimes.com>
>>>> Date:   Sat Feb 13 21:59:05 2016 -0800
>>>> 
>>>>   Bug 739571 - Matching imported transactions doesn't indicate
>>>>   previously
>>>> 
>>>> matched entries
>>>> 
>>>>   Track pending matches from the current import and display this
>>>> 
>>>> information in the match picker.
>>> 
>>> This commit (which I pushed myself) breaks travis because its unit test
>>> uses g_assert_true and friends.
>>> 
>>> A quick lookup shows the maint branch of gnucash is still running travis
>>> tests on Ubuntu 12.04 (Precise), which ships with glib-2.0 2.32 while
>>> g_assert_true was introduced in glib-2.0 2.38.
>>> 
>>> I'm in two minds about how to proceed.
>>> - I could revert the patch and rework it for master only. This will delay
>>> its formal release with a few months.
>>> - I could backport my patches that set the minimum required glib-2.0
>>> version to 2.40 and adjust the travis environment to trusty (14.04) like
>>> master.
>>> 
>>> The fundamental question here is do we still want to support Ubuntu 12.04
>>> ? It will be EOL by the end of next month so I don't know whether it's
>>> still worth spending effort for ?
>>> 
>>> What you others think ?
>> 
>> I suggest the 3rd alternative: Use HAVE_GLIB_2_38 to disable the offending
>> tests on systems that don't support it. Supporting older distros doesn't
>> mean supporting them as development platforms where all tests must work and
>> pass.
>> 
> That's a good option. we already use the same macro for other exceptions. Will 
> implement it that way.
> 
>> For longer term, maint's configure.ac says that it requires 2.28. Has anyone
>> actually tried to build with 2.28 recently? We could set up Travis with
>> various versions of glib to ensure that we don't accidentally break our
>> minimum requirement claims.
> 
> I believe the 2.28 baseline stems from RHEL/Cents 6. It's the most recent 
> version there. I have no idea whether current stable builds on that platform 
> and I'm not sure it ever did. The epel repos only contain gnucash 2.4 so it 
> may well be we have dropped support already in the 2.6 development cycle (I 
> don't remember unfortunately).
> 
> RHEL/Centos 7 ship glib2 2.46.
> 
> openSuse's oldest still maintained release appears to be Leap 42.1 according 
> to Frank's link. This distro ships glib2 2.44.
> 
> Travis/Ubuntu Trusty (14.04LTS) ship glib2 2.40
> Travis/Ubuntu Precise (12.04LTS) ship glib2 2.32
> 
> I mentioned two other distros in my commit message:
> Debian stable ships glib2 2.46 in backports
> Mingw in our Windows environment has glib2 2.42
> 
> So the only two really old ones are RHEL/Centos 6 and Ubuntu Precise (12.04).
> 
> Again I don't know if we ever supported the former with gnucash 2.6. The older 
> will go EOL next month.
> 
> If I find some time I'll see if I can build gnucash 2.6 on Centos 6. I believe 
> I still have a vm somewhere with that distro.
> 
> Can you set up travis with custom glib2 versions ? That looks tricky.
> 
>> 
>> This is also a good time to review our minimum requirements for master, as
>> we've about 4 months until the first beta release and we're switching to
>> WebKit2 so that 2.8 can be in Fedora and that drags in Gtk3. We've also
>> implemented a lot of code that requires at least gcc-4.8 and is happier
>> with gcc-5.0. We need to figure out what versions of the major distros
>> support that, derive from that the minimum version of glib and gtk and
>> clean up the code accordingly, fixing any deprecations as we go.
> 
> Well for glib2 I just did the exercise. All of the above mentioned distros 
> except for RHEL/Centos 6 and Ubuntu Precise are supported if we set the 
> baseline to 2.40. That makes Ubuntu Trusty (and by extension travis as 
> configured for master) the oldest supported release.
> 
> I am only checking distros that are slow in updating here by the way. I assume 
> distros like Fedora, arch and gentoo to be more recent than those (which has 
> always been the case so far).
> 
> As for gcc, again RHEL/Centos 6 and Ubuntu Precise are definitely falling on 
> the wayside.The former ships with  4.4.7, the latter with 4.6.3. I'll just 
> stop mentioning these two distros from now on.
> 
> RHEL/Centos 7: 4.8.5 (gcc 6 available via software collections)
> Mingw: 4.8 (and there are test builds of more recent versions, but not 
> verified with gnucash yet)
> Debian stable 4.9.2
> Ubuntu trusty 4.8.4
> openSuse Leap 4.8 (default), 5.3.1 (available in the repos)
> 
> Gtk3 support. I think at least 3.10 should be the baseline because that 
> version introduces css styling as a replacement for GtkStyle. Maintaining both 
> variants is not desirable. Luckily all platforms we care about for gnucash 2.8 
> match this baseline:
> RHEL/Centos 7: 3.14.13
> Mingw: ?? (Mingw64 has 3.22 - which is recommended by gtk itself as platform 
> for windows)
> Debian stable 3.14.5
> Ubuntu trusty 3.10.8
> openSuse Leap 3.16.7
> 
> Webkit2gtk
> RHEL/Centos 7: 2.4.9
> Mingw: ?? (Mingw64 has 2.4.9)
> Debian stable 2.4.9
> Ubuntu trusty 2.4.10
> openSuse Leap 2.10.7
> 
> boost
> RHEL/Centos 7: 1.53
> Mingw: 1.55 (self built; Mingw64 has 1.63)
> Debian stable 1.55
> Ubuntu trusty 1.54 (1.55 available)
> openSuse Leap 1.58
> 
> Is there anything else we changed requirements for ?

Thanks for working through all of that.

Yes,  ICU, though we don't require a recent version and its API is very stable. There's also Googletest but that's so easy to install from Github that I think we shouldn't worry about it.

There's also gettext (see bug 759844 <https://bugzilla.gnome.org/show_bug.cgi?id=759844>), but that's more an issue for what we use to build release tarballs than anything that users or distro packagers need to be concerned about.

Since MinGW64 supports directly a lot of dependencies that we've been building from source--with significant difficulty in some cases--maybe we should put some effort into redoing the Windows build system to use that instead of vanilla MinGW sooner rather than later.

Regards,
John Ralls