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? > - 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? > 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? > 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? if we ever decide to provide binaries, and assuming we provide them via the current online installer, how will that work? 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? _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
