Compile with qt6 #156
Compile with qt6 #156
Conversation
Note that there are 3 (three) places where QRegExp::setMinimal(true) could not be translated over for lack of a proper equivalent with user-provided patterns.
[draft, targets branch `compile-w-qt6`] Fix use of QRegularExpression + migrate CI to Qt 5
the method in iterators is now a (new size of )
|
I merged in (with some significant massaging) the recent contribution for (again) compiling w/ Qt4. I took the opportunity to also restore compilation w/ Qt5, so now the code in this branch should be compilable w/ whichever major version. Testing the Qt6 compilation shows that searches work properly, including wildcards (!). I continue with the testing for a bit. |
|
It's been >month - is this ready? |
|
Hello Andreas. Thanks for your following this. IRL work takes precedence for me presently. The immediate coding is done. I added a mechanism for (semi-automatically?) choosing the Qt version of the compiling platform (defaulting to Qt6). I did only very cursory testing, but things appeared OK. More testing is needed and, lacking the time, I postponed it. There is the issue of the Qt5Compat use, but I guess this can be lived with for a while. So, what I still need to do:
I might have time for these in July. Until then, I guess this branch is usable. Thanks |
|
@tibirna if the plan is to support both Qt 5 and Qt 6, let's have CI cover both of these (to catch future regressions even before they enter |
`build.yaml`: Build with both Qt 5 and Qt 6 (to detect and prevent regressions)
|
@hartwork Great! Thanks for this. |
|
@tibirna glad you like it! Is anything else missing? |
|
I'll take another look in the next days at the Qt5Compat aspect. If it stays long, I'll make my peace with it and we'll be good to release this as the main qgit code. I intend to call that release qgit-6.0 (no matter what I manage with Qt5Compat). Reasonable? |
@tibirna I believe the encoding converters were the key reason for Qt5Compat. Qt 6 does not seem to support as many encodings any more and I find suggestions to call the
I'm a believer in https://semver.org/ personally where you bump the major version (at least) when breaking some runtime (not compile-time) backwards-compatibility. If QGit 6 indicates use of Qt 6, that would produce a conflict when you introduce backwards-incompatible changes prior to a bump to Qt 7, because a bump would signal the breakage but now also mis-signal use of Qt 7. My favorite would be "3.0.0" with three components. It would be independent from the version of Qt and clearly so, it would signal potential backwards-incompatiblity (say from the move to |
As kde proj maintainer in Gentoo, I am currently counting 52 packages depending on Qt5Compat in git master. There is no reason to make this block a release. //It will certainly stay longer around than Qt5 itself. Re versioning: whatever causes least friction. Qt4 to Qt5 was qgit-2.5 -> qgit-2.6, and the port to Qt6 is an even smaller step than that. Maybe a full major bump would be more justified after big cleanup (Qt4--, Qt5--, qt5compat--) with only bugfix backports and pointreleases in 2.x.x from a legacy branch in the future. |
|
@tibirna thanks for the merge! 🎉 |
|
@hartwork Thank you for the efforts and for the nudging. |
|
@tibirna I'm glad I could help and that now distros will not have to drop QGit packages anymore when they throw out Qt 5 🎉 Is there a QGit 2.12 release party somewhere in Germany? 😃 PS: I just bumped QGit to 2.12 in Gentoo 🍻 |
|
@tibirna PS: I'm only noticing now that release 2.12 is not marked as "latest" up here but 2.11 still is. There is a checkbox for that on the edit release page. Could you mark 2.12 as latest? |
|
@hartwork Thanks for noticing. I'm pretty sure I had it checked initially. Done now. |
Handle API changes and other odds and ends for compiling with Qt6.