[Development] Updates on Qt Location

[Volker Hilsheimer]

Hi,


Lauri Laanmets, Alex, Shawn and myself had a talk about the state of Qt Location and next steps yesterday. Qt Location is not officially available for Qt 6 yet, and here’s what we are going to do about it:

Lauri and others have done a fantastic job of porting most of Qt Location to Qt 6 already, and the discussion in [1] shows that people have been quite successful in using that port by building the dev branch themselves.

[1] https://bugreports.qt.io/browse/QTBUG-96795

However, Qt Location has a long history, and there is plenty of code and functionality that was built based on legacy requirements. Some of that code is not very relevant anymore, and a few things are generally not quite up to Qt 6 standards. What exactly all of this means for the long-term perspective of Qt Location is still a bit unclear, but we do want to be able to make a workable and supportable Qt Location version available to users.

To that end, we are - for the time being - going to deviate from the normal procedure in Qt modules as follows:

- we make Qt Location available as versions that works with Qt 6 LTS releases (ie we’ll have something that works with Qt 6.2, but won’t spend time on making something that is tested against 6.3 or 6.4).
- we exclude the module from binary and source compatibility guarantees
- at least for starters this will be a separate package, possibly even just a branch in git
- that branch excludes the bits that are not meeting our standards

As per the JIRA ticket’s title, the first goal is to get a Qt Location branch in shape that works well against Qt 6.2. Development happens in the dev branch, against the dev-branches of the rest of Qt. So we need a 6.2 branch in Qt Location that includes all the porting work, but no changes that require post-6.2.

That branch is now available on gerrit [2]. Given the status quo and the history in the dev branch including a bunch of dev-only changes (using new build system features and porting away from deprecated APIs), I’ve opted for starting with the old 6.2 branch at revision 6db775f6d9d72cf8ee9d66333b8424e74be1e352, rebased to dev, removed dev-only changes, and squashed the change set. This is now up for review [3].

[2] https://codereview.qt-project.org/gitweb?p=qt/qtlocation.git;a=shortlog;h=refs/heads/lts-6.2
[3] https://codereview.qt-project.org/c/qt/qtlocation/+/423083/2


Once we have reached a baseline where the lts-6.2 branch that builds and passes tests against the upstream 6.2 modules (which is what [3] together with the follow-up submodule update is expected to achieve), we should be able to use the usual cherry-pick process to get further porting changes in. Changes that remove unstable, unfinished, or generally unwanted functionality for the packages we want to release will then be done directly in the lts-6.2 branch. This will probably take out the “labs” functionality and several backends.


When 6.5 branch-off time comes around for Qt, we will create a 6.5 branch for qtlocation off of the dev branch, cherry-pick (some of) the “remove unwanted stuff” changes over from the lts-6.2 branch, and then end up with a Qt Location that works and can be supported on top of Qt 6.5.


Ultimately, this process should converge to a state where Qt Location either becomes a submodule like all others (including SC/BC guarantees); or we might decide to continue with this way of working, e.g. only make new Qt Location versions available for each Qt LTS release (perhaps also with SC/BC guarantees, binary packages, etc). This depends on how many people are going to participate in the work, what other channels we will have to distribute Qt modules outside of the installer, and what we decide to do with this module in the long run.


Volker