Options for patching older Gramps version

Development
1

@codefarmer asked a good question after a patch created by @kku was posted to MantisBT as General type Addon. (Thanks Kari!)

He asked whether it would have been better to post as a PR rather than as an patching Addon?

And, at first glance, that seems the ‘right’ way because it will be a permanent fix. But there are several drawbacks:

  1. there is a long leadtime for bug fix releases for the core application and longer yet for enhancements.
  2. only a small portion of the community can build a Gramps installation from source. So a narrow cross-section of users
  3. the patch will only be applied to active branches. (So users stranded on old versions will not have access to PR-based fixes.)

So perhaps a new testing protocol is warranted? If a change can be posted as a “beta” status Addon, the first step could be to release as an Addon for the current general release. After it passes some field testing, it can be submitted as a PR. And also as a “stable” status addon for as many versions of Gramps as viable, but that the PR will cannot reach.

This would have an added benefit. It will give developers experience creating a GENERAL type addon.

Reference:

  • 0013146: Manage Family Trees dialog does not re-focus on selected tree after Sort (key column or direction) change
2

Re: [1] (I took the liberty of inserting numbers for easy reference), I agree with your observation about the time lag, but that should not preclude creating the PR for Gramps core and I would encourage that in this case.

Implementing @dsblank’s suggestion of moving to faster releases, and even nightly builds would alleviate the lag between PR and release.

If you’re proposing to test a fix/enhancement as an addon first (if it were indeed possible) and then get it ready for Gramps core, feels like a lot of effort, and will require two implementations. I would not be in favor. Apart from the effort issue, back-porting a fix to older builds as an addon (when possible) is a nice strategy!

Ideally, with the pace of enhancements coming in Gramps 6.x, I would imagine that our community would want to move to the newer releases rather than stay with the old even though I understand some people may hold out for various reasons.

3

Thanks. Revised to use numbered list rather than bullet points.

4

Where possible, moving to newer versions is the ideal. However, equipment compatibility can maroon users on certain OS versions. And consequently, limit them to older versions of Gramps.

For pensioners on a tight budget, upgrading to more modern hardware may not be an option.

Microsoft only retired 32-bit Windows hardware in 2020. The last 32-Bit Windows Gramps was v5.1.5 in February 2022.

And Apple does not seem to even hesitate to strand hardware. From osguru :

macOS version Oldest supported desktop-era Macs
Sequoia 15 Mac mini (2018), iMac (2019), Mac Pro (2019)
Sonoma 14 iMac (2019), Mac mini (2018), Mac Pro (2019), Mac Studio (all)
Ventura 13 iMac (2017), Mac mini (2018), Mac Pro (2019), Mac Studio (all)
Monterey 12 iMac (Late 2015), Mac mini (Late 2014), Mac Pro (Late 2013)
Big Sur 11 iMac (Mid 2014), Mac mini (Late 2014), Mac Pro (Late 2013)
Catalina 10.15 iMac (Late 2012), Mac mini (Late 2012), Mac Pro (Late 2013)