It looks like it was merged in Feb 17, 2017. But it is an enhancement rather than a bug fix. And the last enhancement release was 5.1.0 on 21 Aug 2019. The merge should already affect the version you are using.
On the other hand, that commit was really hinky. It was lost and they had to reconstruct it. The upcoming 5.2 release might be the first version that would see that feature in distribution.
Note that the order will not be determine by birthyear. It will follow the order of children set in the family.
I suggest that you download the GrampsAIO-5.2.0-beta2-1_win64.exe test version of the Windows installer from the releases page. Then you can verify that the change was implemented.
Either that, or you can export a sample family that demonstrates the problem. And attach that .gpkg or .gramps file to a reply here with an image of the graph. (Preferably with the problem highlighted.) One of the beta testers could import that family to check if the patch was actually applied and works.
Thanks for the suggestions. I was about to give v5.2.0-beta2-1 a try until I found out it requires upgrading the database schema to from v18(***) to v20, so I am attaching my .gramps DB and the graph with some (but not all) of the out-of-order entries boxed in red.
*** BTW I had thought my DB schema version is already v19 in order for me to use Gramps v5.1.x, but according to the preamble warning of v5.2.0-beta2-1 my DB schema is v18.
Yes, that’s true. This was NOT suggesting that you upgrade to 5.2 prematurely for production work. Fortunately, you can install the beta in parallel to the 5.1.6 version and test on a duplicate/backup tree.
The big question was if the patch had made it into 5.2 and works as expected. Because if we wait until final release to test, the enhancement would slip to 5.3!
If the patch fails in beta the cycle, we need to find out what happened to that 2017 change. Perhaps it did not get folded into the 5.2 master. Or it was accidentally reverted.
There was another fix that was reverted accidentally and was corrected during the beta cycle.
I did understand that you had meant for me to try v5.2.0-beta in parallel with the current 5.1.6 – I just needed a bit of time to organize and replicate my DB
In any event, I now just did that – and it looks like the mis-ordering issue is still there, although the problem manifests in fewer and different spots than in the run with the older version v5.1.6.
Yes, it was that version. Perhaps I was using different report options.
You can swap in my options by replacing the block with those setting in the report_options.xml file of your Gramps User Directory. (The location of the User Directory has changed for 5.2 in Windows. Instead of %appdata%/gramps , the path is %localappdata%/gramps )
Keep a copy of your report_options.xml file. There are too many options to go over each one. But if my setting work on your beta2, then you can compare the text listing of the options and experiment with settings that are different.
If you have both 5.1.x and a 5.2beta installed on the same machine, then you have both.
The appdata/local/gramps will be used by 5.2beta and the appdata/roaming/gramps will be used by the 5.1.x
(Personally, I consider the change to be a flaw in the 5.2 beta cycle. It is arguably the more appropriate location. However, it wasn’t a planned change and was apparently a byproduct of another change. If it had been a planned change, that would’ve been proper. Any accidental change should be erradicated or fully documented with a good reason.)
I uninstalled then reinstalled v5.2b2 – there is still no gramps in \AppData\Local, and in \AppData\Roaming there are both v5.1.6 and v5.2b2.
In any event, I reran the rel_graph – one came out looking to be error free (although I too am having problem validating the orderings without consulting our genealogy book, as many of the ancestor entries don’t have any date ), but another one still has errors in it.
It seems unpredictable if and where the errors would pop up, perhaps because the graphing algorithm used is heuristic, thus different starting points (i.e., “center persons”) would yield different outcomes in terms of error-free.