Hello Tuukka, thanks for your answer.
In my view, as long as the 'rules' for the module(s) is clearly defined, as in this case say if KDAB takes over the official maintainer role, while it still lives under the QtC infra roof, and we still get the modules dropped with the other sub-modules, then it will be business as usual, but downstream has to get some kind of info channel on these kinds of things, are there more modules where this kind of thing happens? one simple downstream info solution could be a small public repo or a news/rss-feed with only the important information as a kind of decision history, say any change in the rules for a sub-module gets a record. example on spectrum on the support on modules: [unmaintained, deprecated, life-support, full-maintenance, feature-development] in my view there should be a better way to communicate the support level in the documentation as well, this page https://doc.qt.io/qt-6.6/qtmodules.html should list some kind spectrum of support for the modules in the table, I've always assumed everything on that list is what QtC has committed to support for the full major version life-cycle if its defined there. for example any deprecation warning about other modules that supersede for 'most use-cases', preferably with some kind of examples of the use-cases where the other alternative is better, should definitely be listed here: https://doc.qt.io/qt-6.6/qt3d-index.html because on that page there is not a word about anything being anything but sunshine and progress forward from Qt5 to Qt6 towards the future. so i guess the only thing left is to see what KDAB will communicate in terms of keeping the lights on the modules support level spectrum, like earlier mentioned list. personally i hope for more than life-support during the rest of 6.x. /Björn On Thu, Mar 28, 2024 at 7:40 AM Tuukka Turunen <tuukka.turu...@qt.io> wrote: > Hi Björn, > > > > In general, we want to provide longevity and still host many items that > are long ago removed from the main product configuration (or never been > part of it). That said, we also need to have a way to sometimes let go of > items in the main product configuration. Platform support is perhaps one of > the most prominent examples of this, but sometimes also add-ons need to be > adjusted. In some ways it is perhaps better not to drop things between > major versions only. Maybe there is no good time, but at least during the > transition from Qt 5 to 6 we got a lot of feedback about not bringing some > modules forward in Qt 6.0. > > > > Qt is modular by structure and the official release is the split source > packages: > https://download.qt.io/official_releases/qt/6.6/6.6.3/submodules/. Of > course, for users no longer having some functionality is a problem, so to > the extent possible we want to keep things available and working also for > those repositories that are not part of the release configuration (and > there are many available at https://code.qt.io). > > > > We can definitely keep Qt 3D available in the repositories, covered by > code review, continue running CI and open for new commits. Like you said, > eventually it is up to the module’s maintainers how well the code continues > to run with new versions (or in case existing ones one day wish to step > down, finding a new ones). Unless there is some bigger change preventing > it, I would also wish to see Qt 3D continue to be available in the > repositories throughout the whole Qt 6 life-cycle, even beyond. > > > > Yours, > > > > Tuukka > > > > *From: *Development <development-boun...@qt-project.org> on behalf of > Björn Strömberg <bjorn.stromber...@gmail.com> > *Date: *Thursday, March 28, 2024 at 04:38 > *To: *Qt Project Development <development@qt-project.org>, Qt3D-Dev < > qt3d-...@kdab.com> > *Subject: *[Development] Fwd: Removing Qt 3D from release configuration > in dev branch > > accidentally replied only to Tuukka (QtC). > > > > forwarding to ML so it gets where it was supposed to be. > > > > > > to be clear, the problem is the admission of support, its left open, i saw > that Giuseppe from KDAB also was on that ball, what happens after 6.8, > its only listed as supported > > · Even though not part of the release configuration, intention is > to keep Qt 3D working also with Qt 6.8 > > > > the wording I'm looking for is 'working with Qt at-least until 7.0' and > when that wording comes into play, it can just as well still be left where > it's in dev.. > > > > so we got a train wreck incoming, that likely will be QtC pushing this > over to KDAB after 6.8, so how long after a 6.x release is it acceptable > that the release of the Qt3D module releases, will QtC still host the > tarballs, > > will the development be done on Qts git trees? > > > > that is really a question that it seems that only KDAB can answer since it > seems that QtC is pushing it over to them without actually saying it open, > but any lag upstream gets even bigger on the way downstream... > > > > /Björn > > > > >> first mail that went wrong > > From: *Björn Strömberg* <bjorn.stromber...@gmail.com> > Date: Thu, Mar 28, 2024 at 2:53 AM > Subject: Re: [Development] Removing Qt 3D from release configuration in > dev branch > To: Tuukka Turunen <tuukka.turu...@qt.io> > > > > So now qt-6.x is effecively only promise backwards-compatible module wise > to 6.8? > > > > As written it's open to interpretion afterwards... > > > > Or will a breaking change in dev vs Qt3D really enforce no release of next > point release unless the ext module actally is API compatible with the new > 6.x minor? > > Its unclear from the mail. > > > > This sounds like it will become a "he said, she said" type of thing > between QtC and KDAB, when stuff starts tilting... > > > > In clear words can a Qt6 released module be dropped before Qt-7.0? > > > > I might read the text like "the devils advocate" and look for errors, but > since the shitty thing with the LTS release of patch releases as open > source from Qt-5.15 forward, I dont trust these "stealth" changes, from > user of the libraries perspective, its the reason i now follow the dev ml > to get info about it before getting bitten. > > > > Personally i was about to use qt3d in a new project since it was shipped > as a module without any deprecation warnings in Qt6, so i assumed life of > it till 7.0 without hassle. > > > > But now i will look outside the Qt Eco system for alternative designs > before deciding path to take for end design. > > > > I might even ditch the whole Qt subsystem in due time, or atleast design > for the possibility. > > > > If this is allowed once what will be the next thing that gets dropped? > > First was open source LTS support, now Qt3d is on the chopping blocks, so > that makes module support uncertain. Due to the combination. > > > > With kind regards > > Björn > > > > On Wed, 27 Mar 2024, 09:40 Tuukka Turunen via Development, < > development@qt-project.org> wrote: > > Hi, > > > > We have been discussing with KDAB about the future maintenance of Qt 3D > module. It is a quite large and complex module, which has for most use > cases by now been superseded by Qt Quick 3D. Since Qt 3D has been available > for a long time, it should continue to be available for those who still > need it. It is also part of all currently supported releases, which would > continue to have it in upcoming patch level releases. > > > > After discussing with KDAB (maintainer of Qt 3D) on how to proceed, we > came up with the following and also agreed that I’ll summarize it for the > Qt project development list: > > · Qt 3D module is removed from official release configuration in the dev > branch, i.e. no longer part of the releases from Qt 6.8 onwards > > · Qt 3D continues to be part of Qt project, it continues to be covered by > CI, and available in the repository for those who want to use it > > · Even though not part of the release configuration, intention is to keep > Qt 3D working also with Qt 6.8 > > · Qt 6.7 and older releases continue to have Qt 3D module in the upcoming > patch releases > > Qt 3D module was initially developed for Qt 4 and then received a major > overhaul for Qt 5. It was also brought forward to Qt 6. Initially the idea > was to offer Qt 3D as a separate item in Qt 6.0 via package manage ( > https://wiki.qt.io/Qt_6.0.0_Modules), but since we were not able to make > this modularity successful, it was included to the release configuration > along with the other add-on modules. Qt Quick 3D is a later addition to Qt, > originating from the contribution from NVIDIA ( > https://www.qt.io/blog/2017/02/20/introducing-qt-3d-studio), initially as > a separate runtime, then refactored into Qt Quick 3D for Qt 5 to achieve > better alignment with Qt Quick 2D and after that completely reworked to be > fully aligned with Qt Quick in Qt 6. > > > > Yours, > > > > Tuukka > > > > > > > > > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > >
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
