> On 21 Jul 2022, at 14:23, Alexandru Croitor <alexandru.croi...@qt.io> wrote: > > Hi, > >> - 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). > > Will there be qtlocation git tags and separate branches for each 6.2 patch > release that becomes available to open source users? Or will it be a single > lts-6.2 branch?
Part of the intention here is that we don’t want to be tied to the release schedule of the rest of Qt, which for Qt 6.2 is anyway too late. Releasing a Qt Location 6.2.0 when Qt is at 6.2.5 makes as little sense as releasing a Qt Location 6.2.5 when there was no Qt Location 6.2.0…4. But branching off doesn’t cost much, and our release scripts have been creating Qt 6.2 branches anyway off of the 6.2 branch in the qt/qtlocation repository, ignoring the fact that the repo is not active in qt5.git. I will need to check if this will happen automatically for the 6.2 lts-branch as well. So, that’s a bridge we will have to build when we know what we have, and when, and for how long we want to keep spending time maintaining this particular version. Ideally, the first Qt Location version that works with the "Qt 6.2 version available at that time" will keep working with future Qt 6.2 versions as well, in which case there’s little value in branching off just so that we have many branches all pointing to the same sha. >> - at least for starters this will be a separate package, possibly even just >> a branch in git > > What is implied by package in this case, a source package? Realistically, anything between “check this sha out” to “here’s a tar-ball”. I don’t think anything beyond that is likely, at least not for “Qt Location for Qt 6.2". It would mean adding more stuff to the packaging machinery for Qt 6.2 (but not to 6.3 or 6.4’s machinery). And since for the time being we don’t want to tie the Qt Location work to the Qt 6.2 release schedules anyway, I think there’ll be little benefit from going beyond “tar-ball". But we might learn that asking users to build Qt Location themselves against their installed Qt 6.2 is asking for too much. >> 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. > > Once Qt 6.5 goes into closed-source-delayed LTS mode (presumably when 6.6 is > released), will qtlocation sources still be available like with the currently > proposed lts-6.2 branch? Probably not, no. The lts-6.2 branch right now will be rather the exception. 6.2 branches already exist and cannot be opened separately for pushes. And doing the work in the tqtc/lts-6.2 branch excludes the people that have done most of the porting work. >> 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). > > If qtlocation becomes a full fledged qt module like all others, will that > imply the switch to closed-source-delayed LTS mode? Anything else would require an explicit decision, at least. > if we ever decide to provide binaries, and assuming we provide them via the > current online installer, how will that work? I can install "Qt Safe Renderer” and “Qt for Automation” components today through the current online installer. I assume that it’s possible to put a hypothetical “Qt Location for Qt 6.2” binary package somewhere from where the online installer can pick it up. > Will qtlocation be built against the latest available open-source LTS sources > (so non-tqtc repo), while all the other modules like Core, Gui continue to be > built against the tqtc repos? Once we provide binaries - let’s see. If we aren’t at the point where Qt Location is just another module, then I hope that we can provide binaries that have been built against a certain Qt 6.x version, and that run against a different patch level. But Qt Location does include private headers from at least QtCore and QtQml, and getting rid of those dependencies might not be a good investment. Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development