robertlipe
commented
2 months ago Are we ready to drop support for Qt5? The current floor is 5.15. 1.9.0 could use 5.12.
Yes, I think so.
as far as old operating systems are concerned: 5.12 supports macos 10.12, windows 7, ubuntu 16.04 5.15 supports macos 10.13, widows 7, ubuntu 18.04. 6.2 supports macos 10.14, windows 10, ubuntu 20.04.
The OS vendors have long since quit supporting all of those, so that doesn't make me sad.
What are the benefits:
We can quit writing code, put it in for review, then having it kicked back because it doesn't work on Qt5. Preserving our own sanity counts for a lot.
- reduced number of CI jobs
Our presumits are pretty slow. I know that threading/subsetting testo and finding a faster valgrind would help a lot.
On one hand, valgrind helped us find a LOT of things when were sometimes using after frees or freeing in the middle or walking off the edge of an array. On the other hand we've moved almost entirely to reference counted structures and containers that almost eliminate that class of problems.
If we were pressured to reduce our presubmit footprint costs or times, I'd consider dropping valgrind, but I don't feel any immediate pressure for that. Do you?
- the opportunity to use some newer classes and or methods introduced in Qt6.
The Qt APIs have been delightfully stable for us for a long time. Release thrash has just been growing smaller in our mirror.
For the leading releases from these packagers:
Fedora is packaging 1.9.0 with Qt5. They have been warned the next release will require Qt6. Modified fedora packaging has been demonstrated to work with Qt6.
Good grief. So much for Fedora being the fast-moving part of Red Hat. They must have adopted IBM's scheduling.
Debian is packaging 1.9.0 with Qt6 already. homebrew is packaging 1.9.0 with Qt6 already.
Good. Good.
macports is packaging 1.7.0 with Qt5. This is a surprise, I thought they had moved on. They appear to have single digit gpsbabel users.
It looks like they have Qt6 available and just aren't using it. So when/if they update to 1.9, they have the option of going to 6 anyway.
If I had a clear afternoon to spend on MacOS specific release work for us, it'd be to figure out the signing thing and let us ship signed binaries to avoid the "install failed, go back to settings and tell it we're really really sure" shuffle. I've been astonished how few complaints we get about that. I guess people installing packages from outside the Apple store are just used to that. Maybe since nobody's complaining, I should forget about that, too, and just keep shipping them unsigned.
Google Earth is on 5, but they haven't taken a release from us in many years.
I don't know of any other external factors keeping us on 5.
Fire at will.
RJL
Are we ready to drop support for Qt5? The current floor is 5.15. 1.9.0 could use 5.12.
as far as old operating systems are concerned: 5.12 supports macos 10.12, windows 7, ubuntu 16.04 5.15 supports macos 10.13, widows 7, ubuntu 18.04. 6.2 supports macos 10.14, windows 10, ubuntu 20.04.
Are we ready to drop support for macos < 10.14, windows < 10, ubuntu < 20.04?
What are the benefits:
For the leading releases from these packagers: Fedora is packaging 1.9.0 with Qt5. They have been warned the next release will require Qt6. Modified fedora packaging has been demonstrated to work with Qt6. Debian is packaging 1.9.0 with Qt6 already. homebrew is packaging 1.9.0 with Qt6 already. macports is packaging 1.7.0 with Qt5. This is a surprise, I thought they had moved on. They appear to have single digit gpsbabel users.