Someone asked today what is the current stable version that is recommended for downloading.
That seemed easy! I immediately started to write back that 5.1.4 was the best, most stable version across the for all platforms and installers… and then I hesitated remembering the Lat/Long reversal glitch but thought: “minor problem, easy patch”.
But then thought: “That’s an invisible DATA CORRUPTION during data entry! So NOT minor.” and “patching requires admin access, So not as easy either.”
So should I recommend 5.1.3 instead?
I managed software development for a number of years.
There is always a possible “bug” in software that is evolving.
It is a management call if a new release should be built due to a serious bug. (Time & money)
However, what needs to be changed ASAP is that the download page needs to publish patches when serious faults are found. When I say serious, I mean something that will corrupt the data.
Right now it seems it is secret unless you stumble onto the problem.
I think patching source code should not be a task for users, even if it is just a few lines of code. It does not matter which version your recommend, in both cases you should mention the lat/lon bug, so new users know it and can avoid data corruption.
We will also need a tool for users to switch back lat/lon values of all the places which have the wrong values, so users don’t have to do the work twice.
Yes. That was before the a Lat/Long bug was found. I am wondering if we should pull back on the recommendation to 5.1.3 (& wasn’t there a Mac version at 5.1.3-2 for an installer recompile?)
I do not recall any data corruption issues fixed in 5.1.4… but one was introduced in that release.
Perhaps we need a quick 5.1.5 release?
The labor for the packaging team and any rough projection for the next release are the big factors.
If the plan is for a 5.2 release within 45-90 days, it seems like a 5.1.5 release might burn some bridges. If it is 90-180 days out, a release is arguable. If the release is 180+ days out, a 5.1.5 seems like a good idea.
(Maybe all the Weblate Translations in addition to the 2 affected Coordinate modules could be rolled in together. Then we could cite the recent Weblate conversion as an additional reason.)
This problem has a workaround… latitude & longitude can be utilized in a fully functional way without needing to do the “Place editor, lat and long text are swapped” (Pull 1290) patch.
Instead of using comma separated Latitude, Longitude in the parsing field, the user can put the data directly in the individual fields. It just requires 2 data entries instead of 1.
The affected field is just a redundant convenience feature (like the Data Entry add-on Gramplet) albeit a more tightly integrated one.
The Lat/Long swapping fix has been added to the 5.1.5 roadmap.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.