Hi

There’s no relationship crisis!

The topic is a legitimate thing to discuss and it was brought up here to get as much feedback as possible from the community.

Mike

On 6 Apr 2024, at 13:04, Mathias Hasselmann <math...@taschenorakel.de> wrote:



I am really confused by this thread.

If I read Jani's mail correctly, the plan is:

    Keep everything as it is, except for adding Qt3D to the installers?

Or more exaggerated:

    Keep everything as it is, except for the official endorsement.

Or even more exaggerated:

    Keep everything as it is, except for the Qt users' convencience?

That's what it looks like to me from the very outside.

    How does this step help the users, the customers, the project, the product?

Am I exaggerating? Am I confused? Or is this all really just Qt Company and KDAB living out a relationship crisis at the expense of users and customers?

Regards, and sorry if I misunderstood things,
Mathias

Am 05.04.2024 um 07:11 schrieb Jani Heikkinen via Development:
Some comments  below

-----Original Message-----
From: Development <development-boun...@qt-project.org> On Behalf Of Mike
Krus via Development
Sent: torstai 4. huhtikuuta 2024 17.14
To: Tuukka Turunen <tuukka.turu...@qt.io>
Cc: Qt Project Development <development@qt-project.org>
Subject: Re: [Development] Removing Qt 3D from release configuration in dev
branch

Hi everyone

Disclaimer: I'm one of the contributors to Qt3D, and a KDAB employee.

As mentioned, early discussions have taken place between KDAB and tQtC
around this issue, although much needs to be clarified as to why, how and when
this happens.

As mentioned by Tuukka, Qt3D was introduced in Qt4 timeline, but didn't make it
into Qt5.
KDAB invested a lot of time in a complete rewrite of the module (don't think it
shares anything with the original) and it was made available sometime in the Qt 5
timeline.  Many contributions have been made since then, including in Qt6 with
the introduction of an RHI based backend (although to this day this doesn't have
feature parity with the GL backend due to limitations of RHI).

But since then things have settled down in the Qt6 branch, no major features have
been added. KDAB has continued to contribute bug fixes, and small features in
support of our clients. So development has indeed been very slow.

So hence came the discussions on retiring Qt3D. KDAB is ok on the principle and
committed to keep maintaining Qt3D in the same manor.

But there's a lot of implications.

So what does "removing qt3d from release configuration" mean for contributors?
- if CI remains, gerrit continue to check commits right? If so, the version of qt this
is built against
  remains controlled by the dependencies.yaml file?
Yes, that's possible and I think that's the idea behind Tuukka's proposal.

- but I also presume qt5.dev integration will no longer affect qt3d? ie there will no
automated checked that
  qt3d continues to build against the rest qt when that changes and the
dependencies.yaml won't  be
  updated automatically?
Not necessarily, we can add qt3d in the dependency update round as extra module if we want to do so. That way qtd3 would be checked pretty much like it is done today. The difference is that it won't block the dependency update round, release etc and won't be part of qt release (binary packages, src packages, git tags etc)

- no more automatic branching?
If we want to keep automatic branching we can still enable it.

- so how does versioning work? Would it be up to maintainer to decide when to
do branches, tags, releases?
If we remove qt3d from release configuration we don't add tags or include it in the release packages. If maintainer wants to "release" new version from qt3d I think it is possible but it shouldn't follow qt releasing schema etc. But what release means in this context? Git tag? src packages somewhere? From the releasing point of view I would not like to see that we remove qt3d from the official release configurations but then start releasing qt3d as its own release; it would just increase our workload...


  And what would be a good strategy for that?
- module life cycle in general needs to be defined.

And what does "removing qt3d from release configuration" mean for
users/developers?
- no longer in the installer, or tarballs?
True

- probably no longer in linux distributions?
- do ABI/API compatibility rules still apply?
- for new projects, no more C++ 3D scene graph API, and no more LGPL licensed
module to do 3d.
  At least not bundled with Qt?
- only way to get the code would be to check it out and build it?
I think this is the way to go.

br,
Jani


- given qt3d is a proper qt module (as opposed to a simple library), including qml
(and it's own) plugins, and
  that it was up to now installed along the rest of Qt, how much work will it be for
existing users to change
  their build to continue getting new versions of Qt3D?
- and finally, how do we warn users of the upcoming change?


While I have no problems with the aim of this, we need to figure out the
important details first before
pulling the trigger.



Mike


On 27 Mar 2024, at 08:39, Tuukka Turunen <tuukka.turu...@qt.io> 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
-
Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts

--
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

Reply via email to