> On 22 Jul 2022, at 23:19, Kevin Kofler via Development > <development@qt-project.org> wrote: > > Volker Hilsheimer wrote: >> - 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). > > IMHO, as long as Qt LTS keeps abusing that loophole in the KDE Free Qt > Foundation contract, this is not acceptable. > > Free Software / Open Source users and distributors (e.g., GNU/Linux > distributions) of Qt are essentially forced to upgrade to the non-LTS > versions, so any module / add-on / external library that only works with LTS > releases is useless for us. > > Kevin Kofler
Hi Kevin, Like I wrote in the initial email in this thread: this way of working is “for the time being” and we might get to the point where Qt Location becomes just another Qt module. I also wrote that this also depends on how many people are going to contribute to the work. If more people join the effort, then I’m sure it’s going to be possible to make sure that the Qt Location that was made available against an LTS release also works with subsequent non-LTS releases. Perhaps this is mostly a matter of minor adjustments to the build system, and testing. But given the amount of private APIs from Qt Quick used in Qt Location, it might require a bit more than that. Bottom line: it is work, and we can’t do everything at once, and we want to get to a stable baseline on top of an available Qt version. From what we see (in download numbers and when talking to customers waiting for Qt Location), making Qt Location work with Qt 6.2 brings the most value to most users, Open Source or otherwise. So that’s what we focus on. Whether we can do more beyond 6.5 - let’s see what we learn in the process, and how many people join the effort. Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
