Re: [Development] Deprecation/removal model going into Qt 6
On søndag 2. juni 2019 11:50:35 CEST Volker Hilsheimer wrote: > > On 1 Jun 2019, at 16:12, Alberto Mardegan > > wrote: > > On 5/31/19 4:24 PM, Volker Hilsheimer wrote: > > > >> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with > >> three years maintenance. We are not expecting lots of people to jump > >> on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when > >> an API was marked as deprecated makes perhaps not that much > >> difference “in real time”. > > > > > > Three years is not a lot of time when moving between major releases. It > > would be nice if the last LTS release in a major release series were > > supported for a longer time (5 years?). > > > > Ciao, > > > > Alberto > > > > How long did it take y’all to move from Qt 4.x to Qt 5.x? > > The move from Qt 2 to Qt 3, and from Qt 3 to Qt 4, is brought up as examples > of bad experiences (but then let’s also consider how terrible Qt would be > today if we would still have to drag Qt 2 or Qt 3 concepts around with us). > But if the goal for Qt 6 is to be rather comparable to the Qt 4 to Qt 5, > how bad would it be? > Of course, milage will vary depending on the nature and size of your > codebase, and I’m sure my colleagues in The Qt Company sales would be happy > to discuss support options, when the time comes. I don't think there's a conflict here: If we had frequent major version bumps, I'd still expect some of these (one version of each major)? To be the LTS version for that major, which will be supported for quite a long time. We can give people ample time to move forward, while still creating new majors. And I think the smaller the time delta between major releases, the easier it is to move forward. Cheers, Frederik > Cheers, > Volker > > ___ > 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
Re: [Development] Deprecation/removal model going into Qt 6
On Wed, Jun 5, 2019 at 9:44 PM André Pönitz wrote: > On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote: > > 2. Delete all uses of the deprecated API from Qt itself > > ... and that *before* the deprecation happens. > > Lately the deprecations left Qt in a state that was still using deprecated > API all over the place, with the people driving the deprecation generally > leaving "fixing" Qt itself and other Qt Project to others. > > To put it bluntly: I consider this anti-social behaviour that is absolutely > *not* in line with the spirit of the Qt Project. > I'd have to agree on that. In general that is, because there are some cases where it's not possible; e.g. when the deprecated class/function is exported for the user and due to our compatibility promises we can't remove it immediately. Before we require the user to clean up their house it'd be really in line for us to do the same. Not to mention that leaving usage of deprecated APis inside the library unnecessarily creates technical debt, which is going to bite sooner or later; if we are lucky, sooner rather than later. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote: > = The meaning of deprecation > > I think of deprecation as a means to tell users that the designers of the > deprecated API think that there is some deep flaw in the API that makes it > harder to use correctly or easier to use incorrectly. Or lacking in any > other desirable software quality realm, and yes that includes performance. Correct. That *includes* (run time) performance. But it also includes other aspects, like API consistency, time to market, cost of maintenance, etc. etc. Different people certainly weigh different aspects differently, but in no case we are in a situation where "run time performance trumps everything". > One important aspect of deprecation, IMO, is that the deprecated API will be > less likely to be properly maintained. So, e.g. by deprecating QLinkedList, > we tell the users that we do _not_ intend to make it feature-compatible with > std::list, e.g. by adding splice(). Deprecating the class is plain overkill for that, it it positively hurts as it makes the Qt offering (and this includes, *again*, a consistent API) less complete. All that's required for "telling the user" is one sentence in the docs, even exactly the one you've just used. > Users may continue to use the class, but they will not enjoy the same > progress that other Qt classes or std::list will exhibit. The continued use would be possible without the deprecation. > I don't think, that, apart from the usual nay-sayers who don't want anything > to change, but also don't contribute, there's much disagreement over how and > what to _deprecate_. I am afraid you are completely wrong on this one, too: You apparently aim at deprecating anything that's not part of your personal usage pattern and/or that is designed to strike another balance between run time performance, maintenance cost, API consistency etc. than the one you personally prefer (which is, I take, "run time performance is all that counts"). There's fundamental disagreement with your views on the reasons of deprecation as such, and this attempt to stamp "naysayers" as irrelevant one way or the other shows a fundamental misunderstanding of the Qt Governance Model, which specifically mentions "Giving the community feedback" as a "Common User contributions". So everyone you try to mark as "naysayer" here is _by definition_ contributing. > = The deprecation life-cycle: > > The question really is: if an API is deprecated, then what? We have, so far, > removed deprecated APIs from the library, or moved it to a QtXSupport > library, which later got removed, too. I think the most Angst comes from the > removal part here. > > Let me try to define the deprecated API lifecycle as follows (dare I call it > 4D? :) > > 1. Deprecate the API in Qt vX.Y, add the new API (if any, some APIs many > simply move down a storey into C++, like Q_FOREACH vs. ranged for-loops; > sometimes, Qt will realise that it's not able to support some API any > longer, like XMLPatterns, or, I'd say, Q*SharedDataPointer) > > 2. Delete all uses of the deprecated API from Qt itself ... and that *before* the deprecation happens. Lately the deprecations left Qt in a state that was still using deprecated API all over the place, with the people driving the deprecation generally leaving "fixing" Qt itself and other Qt Project to others. To put it bluntly: I consider this anti-social behaviour that is absolutely *not* in line with the spirit of the Qt Project. [...] > = Summary > > We should come to a conclusion about the meaning of deprecation, the > life-cycle of deprecated APIs (e.g. how maintained are they, from > deprecation to decommissioning?), the time-spans between the four D's, and, > as a corollary, the weakening of our BC guarantees to exclude deprecated > API. Fine. > Personally, I have no problem with disentangling the API sooner, like > vX.(Y+3) Fine with me in principle, except that I'd suggest to only consider LTS releases for Y. > Personally, I also have no problem with decommissioning the API later (like > not drop stuff first deprecated in vX.Y before v(X+2).0), but this does not > seem to be the plan atm. *dropping* deprecated API should noy happen in minor releases, except when there's strict consensus on the list to do that. > But once an API has been identified as ... for want of a better word: bad, > and a better alternative added, we should never hesitate to deprecate the > old one. Only when there's consensus what "bad" means. And please note that consensus is not established as long as there are "naysayers" that you chose to dismiss. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Wednesday, 5 June 2019 06:31:25 PDT Olivier Goffart wrote:
> That's where inline namespaces could help. (You'd change the name of the
> inline namespace as well so you could link to two libraries that use
> different version of Qt, and it would work. (as long as each of these
> library don't expose Qt in their interface))
Yes and no. Yes, you could use inline namespaces to allow both libraries to be
loaded into memory at the same time.
But this is of limited usefulness if the entire library is namespaced, since
you can't exchange data from one to the other, except using non-Qt data
structures. If you accidentally loaded a plugin linking to the wrong version,
the act of loading wouldn't cause a crash. But you may well do so because
plugins usually have a C interface to provide an access point, which will
cause a loss of the actual type information.
For example, if the plugin has
extern "C" QObject *interface();
and QObject is inline-namespaced into v1 and v2, then if he caller does:
using Fptr = QObject *(*)();
auto init = reinterpret_cast(library.symbol("interface"));
That reinterpret-cast is causing a problem and could cause a crash.
Instead, the entry point needs to carry no C++ symbol, such as:
extern "C" void initPlugin();
And with that, the proper symbols are found by the correct namespaces.
And still cause problems. Imagine one of them needs qApp, but since it's the
wrong version, qApp == nullptr.
Conclusion: you can prevent immediate crash in the case of accidental loading
of the wrong version, but it's still such a horribly bad idea to make that
load, to the point that it's not worth our time.
> Having inline namespace could also in theory then allow to link both with
> Qt5 and Qt6 in the same process.
The ELF symbol versioning can already do that.
> But a namespace has the other inconvenient to break every forward
> declaration.
And that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 05.06.19 07:24, Thiago Macieira wrote: On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer wrote: $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME SONAME libQt5Core.so.5 Note the two numbers in the SONAME. They mean two different thing. Right now, they are equal but they don't have to be. The first one, the one that is part of the library name itself, as found in the -l switch to the compiler, is the *source* version. Newer releases of a library that keeps the same source version indicate that they retained source compatibility with older versions of that library. The second one, the one that only appears after you link, is the binary version. Whenever we break source compatibility, that number changes. So we could have libQt6Core.so.0 released in Qt 6.0, then ibQt6Core.so.1 in Qt 6.3. This would allow both libraries to be co-installable, so applications and libraries that haven't been recompiled can still run, without getting broken. However, the two libraries are not loadable at the same time into memory. And there's also no mechanism that would prevent that from happening. So it's entirely up to the distributor or integrator to make sure that is properly done, including by way of a plugin load. If two binary incompatible versions of the same library get accidentally loaded into memory, very weird things will happen, with really hard to debug issues. So, no, I do not recommend doing this. That's where inline namespaces could help. (You'd change the name of the inline namespace as well so you could link to two libraries that use different version of Qt, and it would work. (as long as each of these library don't expose Qt in their interface)) Having inline namespace could also in theory then allow to link both with Qt5 and Qt6 in the same process. But a namespace has the other inconvenient to break every forward declaration. -- Olivier ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Wed, Jun 5, 2019 at 12:57 AM Kevin Kofler wrote: > IMHO, major versions with source&binary compatibility need to actually > live > much LONGER, not shorter. At least 20-30 years, with the time at least > doubling with every new major release. Or just stop doing compatibility > breaks entirely. > This isn't possible by any practical measure. Unless the API design was so good that it encompassed every possible case and it was designed in such a way that nothing changes, then it could live forever (and yes 20 years is forever). Since the API need to get fixed, polished, refactored and improved, compatibility needs to break from time to time. Keeping compatibility is simply not maintainable and honestly a chimera. Can we drop that topic branch now? Shorter binary-incompatibility cycles, no matter whether you call them > major > versions or start breaking binary compatibility in minor versions (ewww!) > are going to make Qt entirely unmanageable for distributions. Somewhat harder. Entirely unmanageable is an unjustified exaggeration. > We already > have to maintain Qt 3, 4, 5, and soon 6. > Actually we have to maintain 5, we should've moved away from 4 (and I personally know that can be a pain for some codebases), and honestly if you're using (and requiring) Qt3 then you really need to rethink your approach. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME > SONAME libQt5Core.so.5 Note the two numbers in the SONAME. They mean two different thing. Right now, they are equal but they don't have to be. The first one, the one that is part of the library name itself, as found in the -l switch to the compiler, is the *source* version. Newer releases of a library that keeps the same source version indicate that they retained source compatibility with older versions of that library. The second one, the one that only appears after you link, is the binary version. Whenever we break source compatibility, that number changes. So we could have libQt6Core.so.0 released in Qt 6.0, then ibQt6Core.so.1 in Qt 6.3. This would allow both libraries to be co-installable, so applications and libraries that haven't been recompiled can still run, without getting broken. However, the two libraries are not loadable at the same time into memory. And there's also no mechanism that would prevent that from happening. So it's entirely up to the distributor or integrator to make sure that is properly done, including by way of a plugin load. If two binary incompatible versions of the same library get accidentally loaded into memory, very weird things will happen, with really hard to debug issues. So, no, I do not recommend doing this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Konstantin Shegunov wrote: > What about shortening the major version release time, instead of changing > the whole model? IMHO, major versions with source&binary compatibility need to actually live much LONGER, not shorter. At least 20-30 years, with the time at least doubling with every new major release. Or just stop doing compatibility breaks entirely. Shorter binary-incompatibility cycles, no matter whether you call them major versions or start breaking binary compatibility in minor versions (ewww!) are going to make Qt entirely unmanageable for distributions. We already have to maintain Qt 3, 4, 5, and soon 6. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
What about shortening the major version release time, instead of changing the whole model? Say we keep the current model, but instead of doing a major release once in 6-7 years, we fix that to 3 years with two LTS releases - one 1.5 years in, and then the last minor version before the major release. That'd allow to make the cleanup sooner and at the same time keep the promise of compatibility for a reasonably long time. It'd also compress the amount of breakage going in, just due to the time constraint, so should alleviate some of the porting issues (I think). On Tue, Jun 4, 2019 at 8:09 PM Lisandro Damián Nicanor Pérez Meyer < perezme...@gmail.com> wrote: > Hi! > > On Tue, 4 Jun 2019 at 13:46, Mutz, Marc via Development > wrote: > > > > Hi, > > > > This is not meant to be a summary of the thread so far, but the > > definition of a possible solution space: > > > > = The meaning of deprecation > > > > I think of deprecation as a means to tell users that the designers of > > the deprecated API think that there is some deep flaw in the API that > > makes it harder to use correctly or easier to use incorrectly. Or > > lacking in any other desirable software quality realm, and yes that > > includes performance. > > > > One important aspect of deprecation, IMO, is that the deprecated API > > will be less likely to be properly maintained. So, e.g. by deprecating > > QLinkedList, we tell the users that we do _not_ intend to make it > > feature-compatible with std::list, e.g. by adding splice(). Users may > > continue to use the class, but they will not enjoy the same progress > > that other Qt classes or std::list will exhibit. > > > > I don't think, that, apart from the usual nay-sayers who don't want > > anything to change, but also don't contribute, there's much disagreement > > over how and what to _deprecate_. > > Agreed. > > > = The deprecation life-cycle: > > > > The question really is: if an API is deprecated, then what? We have, so > > far, removed deprecated APIs from the library, or moved it to a > > QtXSupport library, which later got removed, too. I think the most Angst > > comes from the removal part here. > > > > Let me try to define the deprecated API lifecycle as follows (dare I > > call it 4D? :) > > > > 1. Deprecate the API in Qt vX.Y, add the new API (if any, some APIs many > > simply move down a storey into C++, like Q_FOREACH vs. ranged for-loops; > > sometimes, Qt will realise that it's not able to support some API any > > longer, like XMLPatterns, or, I'd say, Q*SharedDataPointer) > > > > 2. Delete all uses of the deprecated API from Qt itself > > > > 3. Disentangle the deprecated API from Qt. With this I mean that we take > > the steps necessary, at a point in time when we can, to make a Qt built > > sans deprecated APIs as BiC as possible with one that isn't stripped of > > deprecated APIs. The usual way to do this is to move the implementation > > inline into the header file and make it wrap the new API. The point in > > time traditionally was v(X+1).0, but see below. > > > > 4. Decommission the deprecated API. With this I mean either remove it, > > or spin it off into a library which is no longer maintained by the Qt > > Project. The hope being, that someone (TQC, KDAB, Kevin Kofler) picks up > > maintenance of said library. This can be done at the same time as (3), > > or later. > > Sounds good. > > > = Deprecation and BiC > > > > All the above, except, possibly, the decommissioning stage, are SC. > > Disentanglement is, however, BiC. We have traditionally used new major > > versions as a flag day to do disentanglement, and it seems to some, and > > this is why Peppe started this thread, that the plan is for it to also > > be the flag day for decommissioning. > > > > I think we could make the experience for our users a lot less painful if > > we allowed ourselves the liberty to break BC by disentangling deprecated > > API within major release cycles. I don't think anyone actually needs BC > > from 5.0 to 5.13, and for all intents and purposes, 5.13 is not BC with > > 5.0, because, as attested in this thread, there are behaviour changes > > which make it unlikely that an application compiled against 5.0 runs > > without modifications against 5.13. > > > > It seems to me to be a good compromise to disentangle deprecated API > > right after an LTS. Whether to keep BC-for-DPF (binary compatibility for > > deprecation-free programs, with apologies to Hans Boehm) across two or > > three LTS releases is another question. I'm tending towards three. But > > this would be BiC in the current process. > > The part of doing BiC in major versions is (also?) due to SONAME as > it's (currently) only limited to major versions: > > $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME > SONAME libQt5Core.so.5 > > SONAME *must* be changed with each release that breaks binary > incompatibility. Possible solution? Maybe using SONAMEs like major.lts > could work. In thi
Re: [Development] Deprecation/removal model going into Qt 6
Hi! On Tue, 4 Jun 2019 at 13:46, Mutz, Marc via Development wrote: > > Hi, > > This is not meant to be a summary of the thread so far, but the > definition of a possible solution space: > > = The meaning of deprecation > > I think of deprecation as a means to tell users that the designers of > the deprecated API think that there is some deep flaw in the API that > makes it harder to use correctly or easier to use incorrectly. Or > lacking in any other desirable software quality realm, and yes that > includes performance. > > One important aspect of deprecation, IMO, is that the deprecated API > will be less likely to be properly maintained. So, e.g. by deprecating > QLinkedList, we tell the users that we do _not_ intend to make it > feature-compatible with std::list, e.g. by adding splice(). Users may > continue to use the class, but they will not enjoy the same progress > that other Qt classes or std::list will exhibit. > > I don't think, that, apart from the usual nay-sayers who don't want > anything to change, but also don't contribute, there's much disagreement > over how and what to _deprecate_. Agreed. > = The deprecation life-cycle: > > The question really is: if an API is deprecated, then what? We have, so > far, removed deprecated APIs from the library, or moved it to a > QtXSupport library, which later got removed, too. I think the most Angst > comes from the removal part here. > > Let me try to define the deprecated API lifecycle as follows (dare I > call it 4D? :) > > 1. Deprecate the API in Qt vX.Y, add the new API (if any, some APIs many > simply move down a storey into C++, like Q_FOREACH vs. ranged for-loops; > sometimes, Qt will realise that it's not able to support some API any > longer, like XMLPatterns, or, I'd say, Q*SharedDataPointer) > > 2. Delete all uses of the deprecated API from Qt itself > > 3. Disentangle the deprecated API from Qt. With this I mean that we take > the steps necessary, at a point in time when we can, to make a Qt built > sans deprecated APIs as BiC as possible with one that isn't stripped of > deprecated APIs. The usual way to do this is to move the implementation > inline into the header file and make it wrap the new API. The point in > time traditionally was v(X+1).0, but see below. > > 4. Decommission the deprecated API. With this I mean either remove it, > or spin it off into a library which is no longer maintained by the Qt > Project. The hope being, that someone (TQC, KDAB, Kevin Kofler) picks up > maintenance of said library. This can be done at the same time as (3), > or later. Sounds good. > = Deprecation and BiC > > All the above, except, possibly, the decommissioning stage, are SC. > Disentanglement is, however, BiC. We have traditionally used new major > versions as a flag day to do disentanglement, and it seems to some, and > this is why Peppe started this thread, that the plan is for it to also > be the flag day for decommissioning. > > I think we could make the experience for our users a lot less painful if > we allowed ourselves the liberty to break BC by disentangling deprecated > API within major release cycles. I don't think anyone actually needs BC > from 5.0 to 5.13, and for all intents and purposes, 5.13 is not BC with > 5.0, because, as attested in this thread, there are behaviour changes > which make it unlikely that an application compiled against 5.0 runs > without modifications against 5.13. > > It seems to me to be a good compromise to disentangle deprecated API > right after an LTS. Whether to keep BC-for-DPF (binary compatibility for > deprecation-free programs, with apologies to Hans Boehm) across two or > three LTS releases is another question. I'm tending towards three. But > this would be BiC in the current process. The part of doing BiC in major versions is (also?) due to SONAME as it's (currently) only limited to major versions: $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME SONAME libQt5Core.so.5 SONAME *must* be changed with each release that breaks binary incompatibility. Possible solution? Maybe using SONAMEs like major.lts could work. In this way with each new LTS SONAME could be 6.1, 6.2, etc. But there is also a *huge* amount of libraries/applications that won't get ported in due time. If we get to this we get back to what boost and other does, and clearly has showed it's not the way to go. Possible solution? *Maybe* if moving API to it's own left-to-die library and having a *real easy* way to integrate it in existant projects. And even then, with all the experience of maintaining Qt from the last Qt4 days until now, I still think this is a solution only to be done with major releases. Whatever faster is a call for problems. > = Summary > > We should come to a conclusion about the meaning of deprecation, the > life-cycle of deprecated APIs (e.g. how maintained are they, from > deprecation to decommissioning?), the time-spans between the four D's, > and, as a corollar
Re: [Development] Deprecation/removal model going into Qt 6
Hi, This is not meant to be a summary of the thread so far, but the definition of a possible solution space: = The meaning of deprecation I think of deprecation as a means to tell users that the designers of the deprecated API think that there is some deep flaw in the API that makes it harder to use correctly or easier to use incorrectly. Or lacking in any other desirable software quality realm, and yes that includes performance. One important aspect of deprecation, IMO, is that the deprecated API will be less likely to be properly maintained. So, e.g. by deprecating QLinkedList, we tell the users that we do _not_ intend to make it feature-compatible with std::list, e.g. by adding splice(). Users may continue to use the class, but they will not enjoy the same progress that other Qt classes or std::list will exhibit. I don't think, that, apart from the usual nay-sayers who don't want anything to change, but also don't contribute, there's much disagreement over how and what to _deprecate_. = The deprecation life-cycle: The question really is: if an API is deprecated, then what? We have, so far, removed deprecated APIs from the library, or moved it to a QtXSupport library, which later got removed, too. I think the most Angst comes from the removal part here. Let me try to define the deprecated API lifecycle as follows (dare I call it 4D? :) 1. Deprecate the API in Qt vX.Y, add the new API (if any, some APIs many simply move down a storey into C++, like Q_FOREACH vs. ranged for-loops; sometimes, Qt will realise that it's not able to support some API any longer, like XMLPatterns, or, I'd say, Q*SharedDataPointer) 2. Delete all uses of the deprecated API from Qt itself 3. Disentangle the deprecated API from Qt. With this I mean that we take the steps necessary, at a point in time when we can, to make a Qt built sans deprecated APIs as BiC as possible with one that isn't stripped of deprecated APIs. The usual way to do this is to move the implementation inline into the header file and make it wrap the new API. The point in time traditionally was v(X+1).0, but see below. 4. Decommission the deprecated API. With this I mean either remove it, or spin it off into a library which is no longer maintained by the Qt Project. The hope being, that someone (TQC, KDAB, Kevin Kofler) picks up maintenance of said library. This can be done at the same time as (3), or later. = Deprecation and BiC All the above, except, possibly, the decommissioning stage, are SC. Disentanglement is, however, BiC. We have traditionally used new major versions as a flag day to do disentanglement, and it seems to some, and this is why Peppe started this thread, that the plan is for it to also be the flag day for decommissioning. I think we could make the experience for our users a lot less painful if we allowed ourselves the liberty to break BC by disentangling deprecated API within major release cycles. I don't think anyone actually needs BC from 5.0 to 5.13, and for all intents and purposes, 5.13 is not BC with 5.0, because, as attested in this thread, there are behaviour changes which make it unlikely that an application compiled against 5.0 runs without modifications against 5.13. It seems to me to be a good compromise to disentangle deprecated API right after an LTS. Whether to keep BC-for-DPF (binary compatibility for deprecation-free programs, with apologies to Hans Boehm) across two or three LTS releases is another question. I'm tending towards three. But this would be BiC in the current process. = Summary We should come to a conclusion about the meaning of deprecation, the life-cycle of deprecated APIs (e.g. how maintained are they, from deprecation to decommissioning?), the time-spans between the four D's, and, as a corollary, the weakening of our BC guarantees to exclude deprecated API. Personally, I have no problem with disentangling the API sooner, like vX.(Y+3) Personally, I also have no problem with decommissioning the API later (like not drop stuff first deprecated in vX.Y before v(X+2).0), but this does not seem to be the plan atm. But once an API has been identified as ... for want of a better word: bad, and a better alternative added, we should never hesitate to deprecate the old one. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 03/06/19 23:04, Kevin Kofler ha scritto: Giuseppe D'Angelo via Development wrote: Also, please name me 3 GUI frameworks that have not broken APIs for 30 years. Also also, please name me 3 libraries that have not broken APIs for the 30 years. There is at least one (almost): Win32 has now existed for 26 years without an ABI break. That said, it is painful to use (directly), proprietary, and not portable. But we have to admit that they did really well at maintaining compatibility. Some API has been dropped by Win32 (first that comes in mind is NDDE). Still waiting for the other examples. (Anyhow, last time I checked, the development power behind Qt is a tiny fraction of the one available to Microsoft. I brought up the development bandwidth problem already.) Also also also, at least in the x86-64 world, major "API breaks" at the assembly level have already somehow occurred. And that's an architecture that has been around for less than 20 years. Have they really? Software built for the first x86_64 CPUs still runs unchanged, doesn't it? If you want your software to have security issues, yes. Otherwise you'll need to change your assembly. That's an API break in my book. Qt has also become larger and larger over time (despite the removal of APIs considered obsolete). The removal of APIs in Qt 5 lifetime has been mostly "limited" to dropping entire obsolete modules. No cleanup has been done to deprecated API inside a module. I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and Qt 5 is much larger than Qt 4 was. Qt 6 wants to do that, and the point of this thread is how to minimize the pain. And my point is that the only way to minimize the pain is to just not do that to begin with. There needs to be a point where a library just stops doing new incompatible major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22 years. ... Glibc has done countless API breaks: https://raw.githubusercontent.com/bminor/glibc/master/NEWS The intended _scriptable_ solution is 1) copy and paste Q_FOREACH from qglobal.h into a central header of your project 2) rename all occurrences it to MY_FOREACH 3) done That (telling the users to just copy&paste the code from the library) defeats the whole point of a software library. Because Q_FOREACH does not belong to Qt. How about this: put it in a separate library, publish it to github, and port projects to use _that_ instead? It's still 100% scriptable. This is just *false*. You're (deliberately?) ignoring the cost of memory allocations and deallocations, hiding them in big-O constants, something I already warned you about. I won't then waste time debunking this. If you have a list of 100 800-byte objects and you want to insert an element in the middle of the list, with a reasonable malloc implementation, the ONE allocation together with the 4 MB memmove for QList::insert will be negligible compared to the 400 MB (!) memmove for QVector::insert. Third straw man in three emails. Inserting in the middle of a sequential container with a million elements is NOT a common use case. While at it, why don't you also measure the cost of iterating over the elements, as already suggested in an earlier email? Of course, that doesn't imply that it is not possible to do better, in theory. But is this optimization [SSO] worth the trouble of breaking the ABI? Yes. And that's what I doubt, and you have not stated any arguments for your claim. So you want me to dump here all the existing literature available around the benefits of SSO, for the sake of... what exactly? SSO is not an API break and therefore discussion about it does NOT belong to this thread. Quite bored now, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Giuseppe D'Angelo via Development wrote: > Also, please name me 3 GUI frameworks that have not broken APIs for 30 > years. > > Also also, please name me 3 libraries that have not broken APIs for the > 30 years. There is at least one (almost): Win32 has now existed for 26 years without an ABI break. That said, it is painful to use (directly), proprietary, and not portable. But we have to admit that they did really well at maintaining compatibility. > Also also also, at least in the x86-64 world, major "API breaks" at the > assembly level have already somehow occurred. And that's an architecture > that has been around for less than 20 years. Have they really? Software built for the first x86_64 CPUs still runs unchanged, doesn't it? >> Qt has also become larger and larger over time (despite the removal of >> APIs considered obsolete). > > The removal of APIs in Qt 5 lifetime has been mostly "limited" to > dropping entire obsolete modules. No cleanup has been done to deprecated > API inside a module. I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and Qt 5 is much larger than Qt 4 was. > Qt 6 wants to do that, and the point of this thread is how to minimize the > pain. And my point is that the only way to minimize the pain is to just not do that to begin with. There needs to be a point where a library just stops doing new incompatible major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22 years. > The intended _scriptable_ solution is > > 1) copy and paste Q_FOREACH from qglobal.h into a central header of your > project > 2) rename all occurrences it to MY_FOREACH > 3) done That (telling the users to just copy&paste the code from the library) defeats the whole point of a software library. > This is just *false*. You're (deliberately?) ignoring the cost of memory > allocations and deallocations, hiding them in big-O constants, something > I already warned you about. I won't then waste time debunking this. If you have a list of 100 800-byte objects and you want to insert an element in the middle of the list, with a reasonable malloc implementation, the ONE allocation together with the 4 MB memmove for QList::insert will be negligible compared to the 400 MB (!) memmove for QVector::insert. >> Of course, that doesn't imply that it is not possible to do better, in >> theory. But is this optimization [SSO] worth the trouble of breaking the >> ABI? > > Yes. And that's what I doubt, and you have not stated any arguments for your claim. > CoW and SSO are orthogonal optimizations. folly's fbstring has *both*. They are not entirely orthogonal because CoW only works on strings too large for SSO. SSO strings are always deep-copied by design. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Monday, 3 June 2019 06:26:36 PDT Giuseppe D'Angelo via Development wrote: > > QList::prepend has O(1) amortized and O(n) worst case time complexity. > > QVector::prepend has O(mn) (always!) time complexity. > > > > If you are dealing with a large class or struct, e.g. 800 bytes, then the > > QVector operations are 100 times slower than the QList ones! > > This is just *false*. You're (deliberately?) ignoring the cost of memory > allocations and deallocations, hiding them in big-O constants, something > I already warned you about. I won't then waste time debunking this. Don't forget that QVector is a direct memory access, which is easily predicted by the CPU, so it can read ahead. If you're iterating (accessing!) the elements in QList, you're accessing memory that may not be read-ahead, because it's indirect. It will depend on how the elements were added and the strategy of the memory allocator. Also, please consider the memory considerations. If you have 100 elements of 800 bytes, a QVector will allocate 100*800 + 24 bytes (plus 16 of overhead inside malloc, total 80032 bytes used), whereas QList will allocate 100 * (800 + 8 + malloc overhead) + malloc overhead, for a total of 82416 bytes, or 3% more. Now if your object is 80 bytes instead of 800, the memory usage increase is 29%. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Monday, 3 June 2019 04:34:27 PDT Kevin Kofler wrote: > Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. And yet, we can look at this exactly as an example: if you set the CPU to long mode (a.k.a., 64-bit mode), then a LOT of previously obsolete instructions are dropped, especially those that were 1-byte opcodes. This is akin to what we're looking for here: if you opt in to greater and newer things, we can drop obsolete things you've had years (or decades, in the case of CPU) to port away from. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Monday, 3 June 2019 01:50:26 PDT Giuseppe D'Angelo via Development wrote: > At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus > a couple of pointers or so, to bring it to 64 bytes (~ a cacheline). The minimum size for a QString is 3 pointers, which would be 12 bytes on 32- bit. Given we need at least one byte to indicate that it's SSO o not, that would leave an SSO QString limited to 5 chars, which is not very useful. On 64-bit, it would increase to 11 characters. That is better, but given previous histograms of the size of strings in a real-world application (QtCreator), it's leaving a lot on the table. I think the numbers showed that the most common size was 16, but I don't remember if that was bytes or characters. Either way, the drop to the right of the peak wasn't very sharp. The sweet spot is likely to be between 32 and 48 bytes (15 to 23 characters). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> On 3 Jun 2019, at 13:34, Kevin Kofler wrote: >>> I'd rather get fewer (or even no) new features than losing existing ones. >> >> How is this even an argument? Qt will need to evolve and acquire >> features to remain competitive. Again, development bandwidth is finite: >> either the overall quality decreases or some things have to get dropped. > > Qt has long reached a point where it can be considered complete. Its main > selling point is portability to many different platforms rather than some > specific feature. Additional features don't necessarily need to be in the > main Qt library, but can be in community-developed addons such as KDE > Frameworks or such as the many third-party Qt-based Free Software libraries > out there. (They can also be in Qt-Company-developed Qt Solutions if there > is manpower left for that.) > > Qt has also become larger and larger over time (despite the removal of APIs > considered obsolete). Just compare the size of the Qt 3 tarball with the > size of the Qt 5 monolithic tarball. This is not the result of keeping old > APIs around, but of feature creep. > > So I disagree with the assertion that Qt needs more features to remain > competitive. I suppose the same can be said for Linux distros :) But even if we say that Qt is feature complete: the platforms and technologies we sit on top of will continue to develop and change. For example, OpenGL will sooner or later disappear from macOS. NTFS has had symlinks and junctions, which Qt knows precious little about. HTTP/2 is a thing. Some of the changes necessary to stay relevant on these platforms we can make without breaking APIs; some of them we can’t. For example, QFileInfo::isSymLink is a poor API given the file types on NTFS (shortcut files, ie. .lnk; junctions, which are like hard-links for directories; symlinks; files; directories). Of course, we can keep it around forever while introducing a more nuanced API, but the code that implements the old API is a mess to maintain as well, and will likely interfere with a clean and maintainable implementation of a better API. In addition, sometimes we don’t get it right the first time. In fact, any strategy that is based on the assumption that “we get it perfectly right the first time so that we never have to change it” is bound to fail. I crafted the first version of QAccessible, and I wonder how many of you can be bothered with implementing your accessbility interfaces when you implement your custom widgets or QML controls. That ultimately affects real people, and if we have to break API or ABI to make it more likely that all UI elements are accessible, then let’s please do that. It’s always a trade-off, and each case needs to be discussed. Nobody is recommending that we are mindlessly removing or changing things just because we can. But going the other extreme and saying "nothing must ever change because people will have to change their software” is not better. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 03/06/19 13:34, Kevin Kofler ha scritto: Giuseppe D'Angelo via Development wrote: Il 03/06/19 00:08, Kevin Kofler ha scritto: What you call "obsolete functionality" is functionality that existing code relies on and rightfully expects to remain there. Rightfully? By what right exactly? APIs in libraries are meant to be used. I consider it an entirely reasonable expectation by developers using the APIs that they will not be removed under them because the library developers consider them "obsolete". Imagine the chaos if Intel or AMD decided to remove some random "obsolete" x86 instructions from their CPUs! x86 has kept backwards compatibility with every single instruction for more than 30 years. This is the standard software libraries should be held to, too. Nice try: https://rationalwiki.org/wiki/Straw_man#Forms Specifically: moving the focus from a GUI framework's API to a foundational computer architecture design (which must provide much stronger guarantees). Also, please name me 3 GUI frameworks that have not broken APIs for 30 years. Also also, please name me 3 libraries that have not broken APIs for the 30 years. Also also also, at least in the x86-64 world, major "API breaks" at the assembly level have already somehow occurred. And that's an architecture that has been around for less than 20 years. I'd rather get fewer (or even no) new features than losing existing ones. How is this even an argument? Qt will need to evolve and acquire features to remain competitive. Again, development bandwidth is finite: either the overall quality decreases or some things have to get dropped. Qt has long reached a point where it can be considered complete. Its main selling point is portability to many different platforms rather than some specific feature. Additional features don't necessarily need to be in the main Qt library, but can be in community-developed addons such as KDE Frameworks or such as the many third-party Qt-based Free Software libraries out there. (They can also be in Qt-Company-developed Qt Solutions if there is manpower left for that.) Qt has also become larger and larger over time (despite the removal of APIs considered obsolete). The removal of APIs in Qt 5 lifetime has been mostly "limited" to dropping entire obsolete modules. No cleanup has been done to deprecated API inside a module. Qt 6 wants to do that, and the point of this thread is how to minimize the pain. Just compare the size of the Qt 3 tarball with the size of the Qt 5 monolithic tarball. This is not the result of keeping old APIs around, but of feature creep. "Creep" is questionable; and anyhow off-topic. So I disagree with the assertion that Qt needs more features to remain competitive. And I disagree with this. And even assuming to stop adding new feature,s the _current_ feature set may need refactoring and redesigns, which may mean API breaks. See also Boudewijn Rempt's blog post on the subject: https://valdyas.org/fading/hacking/happy-porting/ I agree with the principle (API breaks are painful), but I strongly disagree with the idea that no API breaks can ever possibly happen. And the specific example is a terrible one to make a point as the resulting API break is trivial to work around (I defined such breakages "scriptable"). The Q_FOREACH to ranged for change is not as easy to port to as people think, because there are at least 2 pitfalls when porting to ranged for: 1. you have to add qAsConst or equivalent or you will be deep-copying your implicitly-shared CoW container, 2. code that was changing the container during the iteration, which worked just fine with Q_FOREACH (because the iteration would still be over the original unchanged container), will now crash without warning. Even qAsConst will not help you get a warning or error for it, because it only constifies the reference for the ranged for itself and not for the code within it. This is effectively deprecating a safe construct for an unsafe one. This is not the intended port, because it's not scriptable. Moving to a range-based for is the long-term solution, but that requires checking all usages. The intended _scriptable_ solution is 1) copy and paste Q_FOREACH from qglobal.h into a central header of your project 2) rename all occurrences it to MY_FOREACH 3) done What's the difference, then? For your code, minimal (just use another macro). But for Qt, that it stops supporting Q_FOREACH, teaching its usage, and advocating for it. An array of pointers is the most efficient data structure in practice (operations are at most O(n)), dropping it in favor of an O(mn) data structure (where m = sizeof(T)) such as QVector is a pessimization. And QList also has the prepend optimization that makes most prepends even O(1) rather than O(n). I don't see why almost everybody hates it. As written, the above makes no sense, as it looks like you're comparing apples and oranges:
Re: [Development] Deprecation/removal model going into Qt 6
On 6/3/19 1:34 PM, Kevin Kofler wrote: So I disagree with the assertion that Qt needs more features to remain competitive. Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that does not make use of the graphics hardware, is begging for being replaced. Quick Controls 1 was once supposed to be such a replacement, but it failed to a degree, that it became a candidate for removal for Qt6. A technology that needs more than 30 QObjects to create a button simply has no rights to survive only because of compatibility considerations. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> APIs in libraries are meant to be used. I consider it an entirely reasonable > expectation by developers using the APIs that they will not be removed under > them because the library developers consider them "obsolete". Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. This is the standard > software libraries should be held to, too. This is common practice to mark API deprecated in one major release and remove them in the next one. It helps not clutter an interface and keep it fresh and updated. Yes, it might break some code, but people will be receiving compiler warnings that some functionality has been marked as not recommended for using, and will have a plenty of time to replace it with recommended solution. Regarding CPU, this is another level. I don't think that this comparison is suitable. I don't want Qt to be in C++ situation: some usable subset and a pile of... old things, left for backward compatibility. Fine, it's already in, but there are no reasons to make it worse. As the framework maintainers we have to be more reasonable, I would say. > Qt has long reached a point where it can be considered complete. Its main > selling point is portability to many different platforms rather than some > specific feature. Additional features don't necessarily need to be in the > main Qt library, but can be in community-developed addons such as KDE > Frameworks or such as the many third-party Qt-based Free Software libraries > out there. (They can also be in Qt-Company-developed Qt Solutions if there > is manpower left for that.) > > Qt has also become larger and larger over time (despite the removal of APIs > considered obsolete). Just compare the size of the Qt 3 tarball with the > size of the Qt 5 monolithic tarball. This is not the result of keeping old > APIs around, but of feature creep. > > So I disagree with the assertion that Qt needs more features to remain > competitive. Qt is modular and is going to be more modular. Are there any problems with not using/building/supplying some modules? Introducing (and maintaining after) new features is cool. Old and unused should be eliminated without mercy :) On 6/3/19 1:34 PM, Kevin Kofler wrote: > Giuseppe D'Angelo via Development wrote: > >> Il 03/06/19 00:08, Kevin Kofler ha scritto: >>> What you call "obsolete functionality" is functionality that existing >>> code relies on and rightfully expects to remain there. >> Rightfully? By what right exactly? > APIs in libraries are meant to be used. I consider it an entirely reasonable > expectation by developers using the APIs that they will not be removed under > them because the library developers consider them "obsolete". Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. This is the standard > software libraries should be held to, too. > >>> I'd rather get fewer (or even no) new features than losing existing ones. >> How is this even an argument? Qt will need to evolve and acquire >> features to remain competitive. Again, development bandwidth is finite: >> either the overall quality decreases or some things have to get dropped. > Qt has long reached a point where it can be considered complete. Its main > selling point is portability to many different platforms rather than some > specific feature. Additional features don't necessarily need to be in the > main Qt library, but can be in community-developed addons such as KDE > Frameworks or such as the many third-party Qt-based Free Software libraries > out there. (They can also be in Qt-Company-developed Qt Solutions if there > is manpower left for that.) > > Qt has also become larger and larger over time (despite the removal of APIs > considered obsolete). Just compare the size of the Qt 3 tarball with the > size of the Qt 5 monolithic tarball. This is not the result of keeping old > APIs around, but of feature creep. > > So I disagree with the assertion that Qt needs more features to remain > competitive. > >>> See also Boudewijn Rempt's blog post on the subject: >>> https://valdyas.org/fading/hacking/happy-porting/ >> I agree with the principle (API breaks are painful), but I strongly >> disagree with the idea that no API breaks can ever possibly happen. And >> the specific example is a terrible one to make a point as the resulting >> API break is trivial to work around (I defined such breakages >> "scriptable"). > The Q_FOREACH to ranged for change is not as easy to port to as people > think, because there are at least 2 pitfalls when porting to ranged for: > 1. you have to add qAsConst or equivalent or you will be deep-copying your > implicitly-shared CoW container, > 2. code that was changing the container during the iteration,
Re: [Development] Deprecation/removal model going into Qt 6
Giuseppe D'Angelo via Development wrote: > Il 03/06/19 00:08, Kevin Kofler ha scritto: >> What you call "obsolete functionality" is functionality that existing >> code relies on and rightfully expects to remain there. > > Rightfully? By what right exactly? APIs in libraries are meant to be used. I consider it an entirely reasonable expectation by developers using the APIs that they will not be removed under them because the library developers consider them "obsolete". Imagine the chaos if Intel or AMD decided to remove some random "obsolete" x86 instructions from their CPUs! x86 has kept backwards compatibility with every single instruction for more than 30 years. This is the standard software libraries should be held to, too. >> I'd rather get fewer (or even no) new features than losing existing ones. > > How is this even an argument? Qt will need to evolve and acquire > features to remain competitive. Again, development bandwidth is finite: > either the overall quality decreases or some things have to get dropped. Qt has long reached a point where it can be considered complete. Its main selling point is portability to many different platforms rather than some specific feature. Additional features don't necessarily need to be in the main Qt library, but can be in community-developed addons such as KDE Frameworks or such as the many third-party Qt-based Free Software libraries out there. (They can also be in Qt-Company-developed Qt Solutions if there is manpower left for that.) Qt has also become larger and larger over time (despite the removal of APIs considered obsolete). Just compare the size of the Qt 3 tarball with the size of the Qt 5 monolithic tarball. This is not the result of keeping old APIs around, but of feature creep. So I disagree with the assertion that Qt needs more features to remain competitive. >> See also Boudewijn Rempt's blog post on the subject: >> https://valdyas.org/fading/hacking/happy-porting/ > > I agree with the principle (API breaks are painful), but I strongly > disagree with the idea that no API breaks can ever possibly happen. And > the specific example is a terrible one to make a point as the resulting > API break is trivial to work around (I defined such breakages > "scriptable"). The Q_FOREACH to ranged for change is not as easy to port to as people think, because there are at least 2 pitfalls when porting to ranged for: 1. you have to add qAsConst or equivalent or you will be deep-copying your implicitly-shared CoW container, 2. code that was changing the container during the iteration, which worked just fine with Q_FOREACH (because the iteration would still be over the original unchanged container), will now crash without warning. Even qAsConst will not help you get a warning or error for it, because it only constifies the reference for the ranged for itself and not for the code within it. This is effectively deprecating a safe construct for an unsafe one. >> An array of pointers is the most efficient data structure in practice >> (operations are at most O(n)), dropping it in favor of an O(mn) data >> structure (where m = sizeof(T)) such as QVector is a pessimization. And >> QList also has the prepend optimization that makes most prepends even >> O(1) rather than O(n). I don't see why almost everybody hates it. > > As written, the above makes no sense, as it looks like you're comparing > apples and oranges: time complexities against space complexities. I'm speaking exclusively of time complexities. The space only matters when it goes into the formula for the time, which is the case for QVector. QList::insert and QList::removeAt have O(n) time complexity. QVector::insert and QVector::removeAt have O(mn) time complexity. QList::prepend has O(1) amortized and O(n) worst case time complexity. QVector::prepend has O(mn) (always!) time complexity. If you are dealing with a large class or struct, e.g. 800 bytes, then the QVector operations are 100 times slower than the QList ones! > The fact is: once one removes the big-O factors and deals with actual > numbers and real world hardware, QVector becomes much better than QList > as a _general purpose_ sequential container. Emphasis on the general > purpose, please. For me, the best general purpose container is the one that makes it hardest to run into big performance bottlenecks. The point being that it should be GENERAL purpose, i.e., work efficiently for as many use cases as possible, even if it requires compromises for some common ones. So an O(n) container is better than an O(mn) one, even if it is often marginally slower. And a container with prepend optimization is better than one without it. I used array-of-pointer data structures almost exclusively even in plain C code and before Qt even introduced QList as it stands now. I find QList's API that hides the pointer dereferences, the allocations to hold the value copies, etc. (i.e., all the tedious parts of
Re: [Development] Deprecation/removal model going into Qt 6
On Sat, 1 Jun 2019 14:36:12 +0200 André Pönitz wrote: > On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote: > > The overall goal here is to make sure that we don’t have to carry > > poorly designed architecture or APIs around with us throughout the Qt > > 6 series, and as long as we care about binary and source compatibility > > within a major series, doing what we can for Qt 6.0 (and doing it > > right) is the only option we have. > > The problem is that we as a whole do not agree what "poorly designed > architecture or APIs" means in detail anymore, sometimes even on a very > fundamental level. > > E.g. the previous consent on Qt providing consistency and convenience > is challenged regularly by some. I don't think there is an actual controversy there; the term "some" already seems to be an overstatement. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote: How is this even an argument? Qt will need to evolve and acquire features to remain competitive. The probably most important module - Qt/Widgets - sits on a graphic stack, that had been identified as not being competitive many years ago. The only reason why the module ( = Qt on the desktop ) remains competitive is the lack of competition - including Qt/Quick modules. My expectation for a major release like Qt6 would be to see Qt/Widgets being migrated to the newer graphic stack - even if this would result in substantial API incompatibilities. Actually each major release should have a story, that has to do with some sort of innovation that might require to remove old stuff. But Qt6 does not seem to have something like this and why is it necessary then f.e to remove deprecated/failed modules like QC1 ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Going back to the beginning of the thread. > On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development > wrote: > > Hi, > > It seems to me that many emails in the earlier deprecation thread were from > users concerned by the problem of removal of functionality. This is not an > old story. > > However, apart from the specifics of why deprecating a certain class / what > to replace it with / etc., there's a bigger thing that needs to be clarified, > which is: what is the deprecation/removal model going into Qt 6. > > > It is my understanding that the current plan is to: > > * _remove_ from Qt 6.0 any API deprecated in Qt 5.x (for any x); > > * in order to ease the migration from Qt 5, any API that is going to be > removed/changed in Qt 6.0 (for any reason) is also going to be deprecated in > Qt 5.latest (5.15 LTS, AFAIU). > > > I guess that the idea is that the port to Qt 6 can then happen in multiple > steps: > > 1) port to Qt 5.latest; > 2) (enable and) fix all deprecation warnings; > 3) port to Qt 6. > > > If this is still the plan, I must say I am not a huge fan of it. It has all > the premises to be another Qt3->4 hit. Specifically: Why do you think so? The plan above is actually stricter than what we did when moving from Qt 4 to Qt 5 (where (2) was only partially done). So I believe that the plan above should not make it harder to move from 5 to 6 than the Qt4->5 move. Unless we go completely crazy with deprecations in 5.15 of course, but that’s something we should be careful about. > > * It assumes that any breaking change will happen in Qt 5 first, signalled > via deprecation macros, then Qt 6 will simply remove the deprecated parts. As > we're already seeing with e.g. QList, this is not happening for all the > possible cases, meaning the porting steps above are incomplete and there will > be some extra porting fallout to take into account. > > * It does not let users move away at their own pace. Qt 6.0 will be > inaccessible for existing Qt 5 software until one has ported away from every > deprecated API. If we keep deprecating things (and add replacements) up to > 5.latest, then this also makes it complicated for users to build libraries > and components targeting both Qt 5 and 6. Removing deprecated functionality always forces the users hands. But at some point it has to be done, or we can never drop anything. And btw, I’m not a fan of simply removing/deprecating tons of things without good reason (so I’m opposed to many of the things Marc brought up in the deprecation thread he initiated). > > Such libraries may end up to only be able to target Qt 5.latest and 6 > together, without resorting to #ifdefs or similar machinery in their code; > the reason is that only 5.latest would have the required replacement APIs for > the ones deprecated in 5.latest / removed from 6.0. > > * It does not make a distinction w.r.t. _when_ an API has been deprecated. > IMHO there is a difference between an API deprecated in 5.0 and one > deprecated in 5.15; users had much more time to port away from the former. > Dropping them both on the floor in 6.0 seems very unfair to me, again forcing > users to tackle the deprecation _immediately_ if they want to port to Qt 6. We can consider a staged approach, but there might be some cases, where we need to do a hard cut to get rid of some very heavy luggage for Qt. Where it doesn’t hurt us as much, deprecating and keeping it around in 6.0 is something we could discuss. > > * It does not make a distinction between APIs for which we have a > straightforward / immediate / scriptable (!) replacement, and APIs for which > we don't (yet we'd like to get rid of them). Keeping the latter APIs as > stable and supported in Qt 6.0 means keeping them since 7.0 and then face > have the same problem again. But simply dropping them means pain for users. As a general rule, we shouldn’t drop something where we do not have a replacement available. But there might be exceptions (XMLPatterns come to my mind). Cheers, Lars > > > Given all the work that went into adding deprecation macros during Qt 5 > lifetime (even the multiple incantations of them), would it be possible > somehow to avoid most of the source breaks caused by removal of the > deprecated APIs? I know that it's easier said than done, as it would require > doing this on a API-by-API basis rather than turning a big switch; but we > could find some compromise somewhere. > > > Anyhow, flame away. > > Thanks for reading, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development ma
Re: [Development] Deprecation/removal model going into Qt 6
> On 3 Jun 2019, at 08:00, Thiago Macieira wrote: > > On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote: >> Well, something has to give. Either >> a) Qt can never remove superseded APIs and classes (which is what >> you suggested previously) and will eventually collapse under its own >> weight, or >> b) Distributors have to deal with the fact that some software >> doesn't port and have to ship every version of qt side-by-side, or >> c) The software that doesn't port has to deal with the fact that it >> will be dropped by distributions. But any software with sufficiently >> many users to warrant packaging by the distributors should be able to >> find a maintainer that at least can keep it compiling. > > The answer is a mix of (b) and (c). Distributions don't ship every version > side by side, just one of each major version. Software that doesn't port gets > dropped when that major version is dropped. Yes. (a) is not an option if we want to keep Qt alive in the long term. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 03/06/19 00:08, Kevin Kofler ha scritto: Ballast (obsolete functionality, for various degree of "obsolete") has to be dropped from time to time, causing API breaks. The question in this thread is how to manage those API breaks to be as painless as possible. What you call "obsolete functionality" is functionality that existing code relies on and rightfully expects to remain there. Rightfully? By what right exactly? I'd rather get fewer (or even no) new features than losing existing ones. How is this even an argument? Qt will need to evolve and acquire features to remain competitive. Again, development bandwidth is finite: either the overall quality decreases or some things have to get dropped. See also Boudewijn Rempt's blog post on the subject: https://valdyas.org/fading/hacking/happy-porting/ I agree with the principle (API breaks are painful), but I strongly disagree with the idea that no API breaks can ever possibly happen. And the specific example is a terrible one to make a point as the resulting API break is trivial to work around (I defined such breakages "scriptable"). Changes such as deprecating or incompatibly rewriting a data structure as central as QList (as seems to be already consensus for Qt 6) are just a major disservice to developers. ... exactly, because it's an API break. How can we minimize the damage? By simply not doing this change, not now, not ever. An array of pointers is the most efficient data structure in practice (operations are at most O(n)), dropping it in favor of an O(mn) data structure (where m = sizeof(T)) such as QVector is a pessimization. And QList also has the prepend optimization that makes most prepends even O(1) rather than O(n). I don't see why almost everybody hates it. As written, the above makes no sense, as it looks like you're comparing apples and oranges: time complexities against space complexities. The fact is: once one removes the big-O factors and deals with actual numbers and real world hardware, QVector becomes much better than QList as a _general purpose_ sequential container. Emphasis on the general purpose, please. Hence, we want Qt to move away from QList (and encourage users to do the same). The point of this thread, once more, was asking how to do that as painlessly as possible. ABI breaks such as the QString SSO (that also seems to be already consensus for Qt 6) are also unnecessary and probably also counterproductive in some use cases. What? Why? For the "unnecessary" part, because Qt has been working fine without QString SSO for years. Nice try: https://en.wikipedia.org/wiki/Appeal_to_tradition Whether it is actually a performance win or not is irrelevant because code manipulating QString is almost never performance-critical. (The bottleneck is typically the user.) "Almost never" is simply wrong (or: [citation needed]). First and foremost, it's wrong because containers and core classes in general are the ones MORE likely to be used in performance critical scenarios. Second, string classes in all major C++ libraries and frameworks are deploying SSO *because* it is a performance win. Third, in a library, *every codepath* is a bottleneck for some user, so the library must to be as efficient as possible everywhere. For the "probably also counterproductive" part: * Because there are surely architectures or environments where copying 256 bytes (or whatever the SSO max length actually is) This is a straw man argument, specifically an exaggeration. At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus a couple of pointers or so, to bring it to 64 bytes (~ a cacheline). * Because the total memory use for an array of QString will likely be higher, due to the padding (space reserved for SSO)? ... or much, much, much lower because you don't have to allocate every string's payload separately. * Because it means a QString will no longer fit in a pointer slot, which breaks the QList optimization and is the main reason why people want to get rid of QList as we know it now? QString with SSO will make Qt5List work in array-of-pointers mode, instead of pure vector mode, yes. But the decision of moving away from QList had very little to do with this particular point. And we already had our share of this: QList, QList, QList, and so on, see the other email. ***ANYHOW***: This thread was about managing API breaks. Adding SSO to QString is not meant to be an API break (*). Please stop derailing the thread. (*) Emphasis on _meant_, because obviously it yields observable side effects. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Developm
Re: [Development] Deprecation/removal model going into Qt 6
On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote: > Well, something has to give. Either > a) Qt can never remove superseded APIs and classes (which is what > you suggested previously) and will eventually collapse under its own > weight, or > b) Distributors have to deal with the fact that some software > doesn't port and have to ship every version of qt side-by-side, or > c) The software that doesn't port has to deal with the fact that it > will be dropped by distributions. But any software with sufficiently > many users to warrant packaging by the distributors should be able to > find a maintainer that at least can keep it compiling. The answer is a mix of (b) and (c). Distributions don't ship every version side by side, just one of each major version. Software that doesn't port gets dropped when that major version is dropped. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sunday, 2 June 2019 16:39:24 PDT Kevin Kofler wrote: > PS: Imagine the outcry and havoc if Intel decided to tell you, e.g.: "Sorry, > x87 floating-point is obsolete and hard for us to maintain, we will drop it > from our next generation of CPUs and force everybody to port their software > to SSE2 or AVX512 for all floating-point operations." (I hope I'm not > giving them ideas…) Yet, for some reason I cannot fathom, this exact > behavior is considered acceptable from software library vendors (and > compiler vendors too, g++ is a bad offender there, but that is off-topic > here ). I don't think anyone is thinking of removing x87 support from mainline CPUs, since it's the thing that gives us "long double". It was absent from the Quark microcontrollers, though, just like the original 80386 and 80486SX did. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sunday, 2 June 2019 15:29:11 PDT Manuel Bergler wrote: > > Repeat after me: inline namespaces are not a tool to retain ABI. > > Of course they are. That's the reason they were introduced [0]: To > allow symbol versioning as part of the language without having to > write linker scripts, thus enabling standard library vendors to ship > both C++98 and C++11 conforming versions of the standard library types > in the same binary. Except that this is inaccurate and just plain wrong. I don't care what the intention of the authors of the feature was, it's not to be used for keeping ABI. > > They may allow the library to provide both ABIs. That only makes the > > breakage move to the next library that uses those classes. > > The use itself is not the problem, only using them in public > interfaces will cause problems. But in that case inline namespaces > also allow users that are not able to update such a library to > explicitly request the old version by fully qualifying the type (e.g. > ::v61::QString instead of just QString). It would also be possible to In other words, a *non-inline* namespace? > create a feature toggle macro similar to libstdc++'s > _GLIBCXX_USE_CXX11_ABI to automatically switch which namespace becomes > the default one, but I'd not do that as this will incentivize users > not to update to the newer version. Thank you for using as example the last C++ change that caused Linux distributions to recompile EVERYTHING C++ (except the Qt libraries) because it broke compatibility. I don't know why libstdc++ folks bothered with the ABI tag. Everything needed a rebuild, so they may as well have just changed the soname. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am Mo., 3. Juni 2019 um 02:21 Uhr schrieb Konstantin Shegunov : > > On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote: >> >> Why should software be different? > > > It shouldn't, as already pointed out. That's why well behaved libraries try > to keep compatibility in some reasonable margins. > To throw one more stone here - are you willing to backport patches from > latter minor versions to former ones? When the API and ABI breaks often that > isn't very trivial, is it? In my experience it isn't changes in the API but changes in the implementation that make backporting hard. If, say, an API was changed from taking a boolean parameter to an enum than backporting a patch doesn't cause many problems, if instead the API has stayed the same but the implementation now uses 3 helper classes that weren't there before than it becomes tricky. So I'd say API and ABI stability don't have much impact on backporting patches. > > On Mon, Jun 3, 2019 at 2:47 AM Manuel Bergler wrote: >> >> a) Qt can never remove superseded APIs and classes (which is what >> you suggested previously) and will eventually collapse under its own >> weight, or > > > It can under the current model where API and ABI breaking may happen between > major versions, which I find rather reasonable. > Which is once every 7 (?) years, and even then we can't agree on what to get rid of because getting rid of all problematic APIs would cause so many breaking changes that no one is willing to port all of that and you'd definitely end up with something similar to the Python 2/3 split. >> >> b) Distributors have to deal with the fact that some software >> doesn't port and have to ship every version of qt side-by-side, or > > > Like they do with boost? Which they don't, obviously. > It simply ain't going to happen they're not an infinite well of computer and > human time. > > Also are you suggesting that all applications sync up theirs to your release > cycle? Or are the distros to do that? I think I wasn't clear enough with how I imagine breaking API changes to work. I'm not suggesting to just change the API and/or ABI whenever just for the sake of it. There needs to be a properly documented migration path, possibly with a decision tree if the replacement isn't straight forward. Once internally we agree on a migration path, first implement the replacement API and in the same version that ships that API mark the old one deprecated. In the deprecation message should also be a link to the document explaining how to migrate. And in the following minor release remove the previously deprecated API. For example, assuming QTimer didn't have the API taking std::chrono parameter already, one could introduce that API in Qt 6.0 and simultaneously mark the one taking plain integers as deprecated. In Qt 6.1 I'd remove the old API. That way, assuming everyone has ported to minor version `n` properly, distributions can roll out minor version `n + 1`. Of course, as someone else already suggested we could also have deprecations and consequently removal only in LTS versions, I don't really care. What I do care about is the ability to evolve the APIs in such a way that they become easier to use correctly, easier to teach and harder to accidentally misuse, without having to maintain APIs that shouldn't be used anyway. > If porting the application between minor versions takes more time than the > time to introduce a breaking change, then you're never going to port anything > as this is all you're going to do ultimately. That's the entire point of spreading the breaking changes out; it should never take more than a few days to port to the new version. >> c) The software that doesn't port has to deal with the fact that it >> will be dropped by distributions. But any software with sufficiently >> many users to warrant packaging by the distributors should be able to >> find a maintainer that at least can keep it compiling. > > > Keeping something compiling is different from keeping something working; not > to mention that API breaks are non-trivial to port. Yeah, I should have written "working" instead of "compiling". However, I find that API breaks are typically easy to port as long as there is a documented migration part; most changes can be done by simple search-and-replace. As I already mentioned before, the silent behavior changes are what makes porting slow. > Also this is not a distributions' problem exclusively. Clients of Qt expect, > and rightfully so, binary compatibility which was promised. It is only promised for Qt5, which is why we're having the discussion whether that promise should also hold for Qt 6. > It wouldn't be surprising to me to find an ebb of usage if we start breaking > the ABI every 6 months just because we decided we can. I don't even want to > venture into the rabbit hole that is 6-month lifetime of APIs. Just to reiterate, I'm not suggesting to just break ABI because we can, I just want to allow it for the cases where everyo
Re: [Development] Deprecation/removal model going into Qt 6
On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote: > Why should software be different? It shouldn't, as already pointed out. That's why well behaved libraries try to keep compatibility in some reasonable margins. To throw one more stone here - are you willing to backport patches from latter minor versions to former ones? When the API and ABI breaks often that isn't very trivial, is it? On Mon, Jun 3, 2019 at 2:47 AM Manuel Bergler wrote: > a) Qt can never remove superseded APIs and classes (which is what > you suggested previously) and will eventually collapse under its own > weight, or > It can under the current model where API and ABI breaking may happen between major versions, which I find rather reasonable. > b) Distributors have to deal with the fact that some software > doesn't port and have to ship every version of qt side-by-side, or > Like they do with boost? Which they don't, obviously. It simply ain't going to happen they're not an infinite well of computer and human time. Also are you suggesting that all applications sync up theirs to your release cycle? Or are the distros to do that? If porting the application between minor versions takes more time than the time to introduce a breaking change, then you're never going to port anything as this is all you're going to do ultimately. c) The software that doesn't port has to deal with the fact that it > will be dropped by distributions. But any software with sufficiently > many users to warrant packaging by the distributors should be able to > find a maintainer that at least can keep it compiling. > Keeping something compiling is different from keeping something working; not to mention that API breaks are non-trivial to port. Also this is not a distributions' problem exclusively. Clients of Qt expect, and rightfully so, binary compatibility which was promised. It wouldn't be surprising to me to find an ebb of usage if we start breaking the ABI every 6 months just because we decided we can. I don't even want to venture into the rabbit hole that is 6-month lifetime of APIs. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am Mo., 3. Juni 2019 um 01:35 Uhr schrieb Kevin Kofler : > > Manuel Bergler wrote: > > And this is where we come full circle :) Yes, FOSS needs to port, so > > we should make porting as easy as possible. In particular, there > > shouldn't be too many breaking changes all at once as that would make > > porting a multi-month project. Instead, spread out the breaking > > changes by also allowing them in minor releases. > > And it has already been pointed out elsewhere in this thread that this would > be an absolute nightmare for distributions! The major releases are enough of > a pain as it stands now, having to keep old minor releases around too > (because some software will just never get ported, no matter how small the > required changes are) is just not workable. Well, something has to give. Either a) Qt can never remove superseded APIs and classes (which is what you suggested previously) and will eventually collapse under its own weight, or b) Distributors have to deal with the fact that some software doesn't port and have to ship every version of qt side-by-side, or c) The software that doesn't port has to deal with the fact that it will be dropped by distributions. But any software with sufficiently many users to warrant packaging by the distributors should be able to find a maintainer that at least can keep it compiling. Best Manuel ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Kevin Kofler wrote: > But we do have the expectation that the CPU will still run our 10-year-old > code without having to recompile it. Modern CPUs are backwards-compatible > with restrictions (e.g., you cannot use 16-bit code from a 64-bit OS, at > least not without dangerous hacks) all the way to the 8080 from 1974, and > fully backwards-compatible all the way to the 80386 from 1985! Qt does not > even come close to that level of backwards compatibility. PS: Imagine the outcry and havoc if Intel decided to tell you, e.g.: "Sorry, x87 floating-point is obsolete and hard for us to maintain, we will drop it from our next generation of CPUs and force everybody to port their software to SSE2 or AVX512 for all floating-point operations." (I hope I'm not giving them ideas…) Yet, for some reason I cannot fathom, this exact behavior is considered acceptable from software library vendors (and compiler vendors too, g++ is a bad offender there, but that is off-topic here :-) ). Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Manuel Bergler wrote: > And this is where we come full circle :) Yes, FOSS needs to port, so > we should make porting as easy as possible. In particular, there > shouldn't be too many breaking changes all at once as that would make > porting a multi-month project. Instead, spread out the breaking > changes by also allowing them in minor releases. And it has already been pointed out elsewhere in this thread that this would be an absolute nightmare for distributions! The major releases are enough of a pain as it stands now, having to keep old minor releases around too (because some software will just never get ported, no matter how small the required changes are) is just not workable. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am Mo., 3. Juni 2019 um 01:20 Uhr schrieb Konstantin Tokarev : > 03.06.2019, 02:10, "Manuel Bergler" : > > Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler > > : > > > >> What you call "obsolete functionality" is functionality that existing code > >> relies on and rightfully expects to remain there. > >> > >> I'd rather get fewer (or even no) new features than losing existing ones. > >> > >> See also Boudewijn Rempt's blog post on the subject: > >> https://valdyas.org/fading/hacking/happy-porting/ > > > > I fully disagree with the sentiment in that blog post. If you don't > > want to port, fine, but then also use whatever version of Qt you were > > using before and don't try to use the latest and greatest. > > But FOSS software has to port, or it will be deemed to be "unmaintained > application, which then rightfully should get dropped by distributions" > (quoting Giuseppe's mail). And this is where we come full circle :) Yes, FOSS needs to port, so we should make porting as easy as possible. In particular, there shouldn't be too many breaking changes all at once as that would make porting a multi-month project. Instead, spread out the breaking changes by also allowing them in minor releases. Best Manuel ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Manuel Bergler wrote: > I fully disagree with the sentiment in that blog post. If you don't > want to port, fine, but then also use whatever version of Qt you were > using before and don't try to use the latest and greatest. But that is a luxury we simply do not have in the Free Software world where Qt gets upgraded system-wide for an entire distribution and all applications are expected to get ported to the latest version whether they actually need it or not. (Even if the distribution ships old versions of Qt as compatibility libraries, applications depending on them get frowned upon and sooner or later end up dropped from, e.g., live CD/DVD/USB media, so that the media has to ship only 1 version of Qt.) You are thinking purely from the perspective of a proprietary commercial application where the developing company just picks a version of Qt and bundles it. This is simply not how things work for a large section of the Qt ecosystem. > Technology evolves, deal with it. With hardware no one seems to have the > expectation that you can take your 10 year old desktop computer and > just replace the CPU with a state-of-the-art version. But we do have the expectation that the CPU will still run our 10-year-old code without having to recompile it. Modern CPUs are backwards-compatible with restrictions (e.g., you cannot use 16-bit code from a 64-bit OS, at least not without dangerous hacks) all the way to the 8080 from 1974, and fully backwards-compatible all the way to the 80386 from 1985! Qt does not even come close to that level of backwards compatibility. As for just replacing the CPU without having to replace all the other hardware, that used to be much easier in the past, where socket architecture did not change so frequently, and where there were also "overdrive" solutions for new CPUs on old sockets. This has been deliberately broken by hardware vendors as a means of lock-in, to force you to buy at least a new motherboard (including a new chipset from the CPU vendor, so extra profit for them) along with your new CPU (and then that, in turn, may force you to replace some more hardware due to incompatible interfaces). But even in hardware, there are good examples, such as USB, where you even have forward&backwards compatibility: you can use USB 1 or 2 peripherals on a USB 3 port or the other way round. It will automatically negotiate the best possible speed for you. This is how things should always work! > Why should software be different? Why should everyone have to pay just so > some people unwilling to invest minimal effort to maintain their 10+ year > old code-base can use the newest version of Qt? Because it allows entire software distributions to ship only one version of Qt, the latest, and have all their software work on it no matter what version each upstream developed with. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
03.06.2019, 02:10, "Manuel Bergler" : > Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler > : > >> What you call "obsolete functionality" is functionality that existing code >> relies on and rightfully expects to remain there. >> >> I'd rather get fewer (or even no) new features than losing existing ones. >> >> See also Boudewijn Rempt's blog post on the subject: >> https://valdyas.org/fading/hacking/happy-porting/ > > I fully disagree with the sentiment in that blog post. If you don't > want to port, fine, but then also use whatever version of Qt you were > using before and don't try to use the latest and greatest. But FOSS software has to port, or it will be deemed to be "unmaintained application, which then rightfully should get dropped by distributions" (quoting Giuseppe's mail). > Technology > evolves, deal with it. With hardware no one seems to have the > expectation that you can take your 10 year old desktop computer and > just replace the CPU with a state-of-the-art version. Why should > software be different? Why should everyone have to pay just so some > people unwilling to invest minimal effort to maintain their 10+ year > old code-base can use the newest version of Qt? > > Best > Manuel > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler : > What you call "obsolete functionality" is functionality that existing code > relies on and rightfully expects to remain there. > > I'd rather get fewer (or even no) new features than losing existing ones. > > See also Boudewijn Rempt's blog post on the subject: > https://valdyas.org/fading/hacking/happy-porting/ > I fully disagree with the sentiment in that blog post. If you don't want to port, fine, but then also use whatever version of Qt you were using before and don't try to use the latest and greatest. Technology evolves, deal with it. With hardware no one seems to have the expectation that you can take your 10 year old desktop computer and just replace the CPU with a state-of-the-art version. Why should software be different? Why should everyone have to pay just so some people unwilling to invest minimal effort to maintain their 10+ year old code-base can use the newest version of Qt? Best Manuel ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am So., 2. Juni 2019 um 18:56 Uhr schrieb Lisandro Damián Nicanor Pérez Meyer : > > Hi! With my Debian maintainer hat on: > > On Sun, 2 Jun 2019 at 05:21, Manuel Bergler wrote: > > > > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler > > : > >> > >> Volker Hilsheimer wrote: > [snip] > >> Your proposal to break ABI at every 6.x minor release would be an absolute > >> nightmare for distributors. It would no longer be possible to upgrade > >> stable > >> releases of a distribution like Fedora to a new Qt as is frequently done > >> now. Rolling-release distros would also suffer, having to go through a > >> coordinated mass transition each time. And third-party PPAs upgrading Qt > >> for > >> a stable distribution would also become harder to offer (because they would > >> have to rebuild ALL Qt-using packages, not just those (ab)using private > >> APIs). I do not see how this would be an improvement over the current > >> situation at all. > > Same goes for Debian, Ubuntu and (¿the vast majority?) of distros out there. > > > There are at least two ways Qt and/or distributors could deal with ABI > > incompatible changes in minor releases of Qt 6. First of all, Qt itself > > could make use of inline namespaces to ship several version of the same > > classes in the same binary while keeping source compatibility. And if Qt > > doesn't want to go that route because of maintenance overhead then the > > distributors themselves could decide not to ship just a single version of > > Qt, but rather have multiple versions side-by-side using the custom > > namespace and library infix option already provided by Qt. > > In both cases it's a great burden. In one case in the Qt developers's > shoulders (much worse that keeping API/ABI stability) and in the other > in maintainers's shoulders. On the the **great** things Qt provides is > actually API/ABI stability. I do understand that maybe it's not seen > by many, but indeed is one of it's major strengths. I can see the point that for distribution maintainers API and ABI stability are great assets. But I also think in the long term it will kill Qt as it prevents Qt from evolving. We don't want to have too many breaking changes at once when upgrading to a new major version, because that will lead to slow adoption as the benefits of the new features does not outweigh the cost of updating for at least the first few minor releases. Yet, with the current model, we also can't have breaking changes in minor releases, so effectively nothing can ever be changed. The best example I think is the QList discussion. It is almost universally accepted that QList is bad, yet even there we can't seem to get consensus to just get rid of it with no replacement and having the users deal with it. Not being able to remove badly designed classes and APIs will cause them to be used even in newly written code when the next major release is around the corner, thus - by induction - needing to be maintained (and taught!) indefinitely. Best Manuel ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am So., 2. Juni 2019 um 19:18 Uhr schrieb Thiago Macieira : > > On Sunday, 2 June 2019 01:20:51 PDT Manuel Bergler wrote: > > First of all, Qt itself > > could make use of inline namespaces to ship several version of the same > > classes in the same binary while keeping source compatibility. > > Repeat after me: inline namespaces are not a tool to retain ABI. Of course they are. That's the reason they were introduced [0]: To allow symbol versioning as part of the language without having to write linker scripts, thus enabling standard library vendors to ship both C++98 and C++11 conforming versions of the standard library types in the same binary. > They may allow the library to provide both ABIs. That only makes the breakage > move to the next library that uses those classes. The use itself is not the problem, only using them in public interfaces will cause problems. But in that case inline namespaces also allow users that are not able to update such a library to explicitly request the old version by fully qualifying the type (e.g. ::v61::QString instead of just QString). It would also be possible to create a feature toggle macro similar to libstdc++'s _GLIBCXX_USE_CXX11_ABI to automatically switch which namespace becomes the default one, but I'd not do that as this will incentivize users not to update to the newer version. Best Manuel [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Giuseppe D'Angelo via Development wrote: > Il 01/06/19 23:34, Kevin Kofler ha scritto: >> But the problem for developers is NOT the 5.x releases that do not break >> the API. Those are great! The problem is those n.0 releases that DO break >> the API. And the solution there would be to just stop doing this kind of >> releases. > > But this is simply impossible. It would require an infinite development > bandwidth, and at a certain point, may constrain development too much. There is a finite amount of code, so the required development bandwidth is also finite. :-) > Ballast (obsolete functionality, for various degree of "obsolete") has > to be dropped from time to time, causing API breaks. The question in > this thread is how to manage those API breaks to be as painless as > possible. What you call "obsolete functionality" is functionality that existing code relies on and rightfully expects to remain there. I'd rather get fewer (or even no) new features than losing existing ones. See also Boudewijn Rempt's blog post on the subject: https://valdyas.org/fading/hacking/happy-porting/ >> Changes such as deprecating or incompatibly rewriting a data >> structure as central as QList (as seems to be already consensus for Qt 6) >> are just a major disservice to developers. > > ... exactly, because it's an API break. How can we minimize the damage? By simply not doing this change, not now, not ever. An array of pointers is the most efficient data structure in practice (operations are at most O(n)), dropping it in favor of an O(mn) data structure (where m = sizeof(T)) such as QVector is a pessimization. And QList also has the prepend optimization that makes most prepends even O(1) rather than O(n). I don't see why almost everybody hates it. >> ABI breaks such as the QString >> SSO (that also seems to be already consensus for Qt 6) are also >> unnecessary and probably also counterproductive in some use cases. > > What? Why? For the "unnecessary" part, because Qt has been working fine without QString SSO for years. Whether it is actually a performance win or not is irrelevant because code manipulating QString is almost never performance-critical. (The bottleneck is typically the user.) For the "probably also counterproductive" part: * Because there are surely architectures or environments where copying 256 bytes (or whatever the SSO max length actually is) is more expensive than copying a 4-to-8-byte pointer and incrementing an atomic reference count? SSO bypasses CoW and forces you to copy the whole string by value. This may be a win on current x86 architectures where atomics are really expensive, but it is surely not universally true. * Because the total memory use for an array of QString will likely be higher, due to the padding (space reserved for SSO)? * Because it means a QString will no longer fit in a pointer slot, which breaks the QList optimization and is the main reason why people want to get rid of QList as we know it now? >> Your proposal to break ABI at every 6.x minor release would be an >> absolute nightmare for distributors. > > I personally interpreted "continuous flow of carefully managed changes" > as "small" API breaks, not (just) ABI breaks. Breaking API automatically also breaks ABI, so it is worse. Distributors would still have to deal with all the ABI breakage nightmare, but in addition, API changes may require patches to the software to be able to rebuild it against the new ABI. And if your API change is actually a removal, the software might not be easily patchable at all and distributors might be forced to ship yet another Qt compatibility library forever. (We are already stuck with Qt 3, 4, and soon 5 as compatibility libraries.) Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Manuel Bergler wrote: > I myself don't mind the 2 weeks it took so far to upgrade from Qt 5.9 to > Qt 5.12 in our project, that's just the cost of progress... I guess one of the reasons that you are feeling more migration pain than the FOSS projects is because you skip all the non-LTS branches, whereas the FOSS world upgrades one branch at a time. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Lisandro Damián Nicanor Pérez Meyer wrote: > Boost is **exactly** the best example of why Qt should not go the same > route. It's totally problematic to have more than two stacks around, > and we **will** have Qt5 and Qt6 for a long time. In fact, Fedora even still ships Qt 3 and Qt 4 and they are not going away any time soon! Some applications will never get ported. What's the benefit of the new features in new Qt releases if your application works just fine without those features? The most important feature in a library is backwards compatibility! Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sun, 2 Jun 2019 at 13:59, Lisandro Damián Nicanor Pérez Meyer wrote: > > On Sun, 2 Jun 2019 at 10:10, Allan Sandfeld Jensen wrote: > [snip] > > > > > I have no problem with breaking ABI more often but allowing it in every > > minor > > releases probably goes to far. Perhaps every second LTS (every 3 years), > > might > > be better. > > That would work as long as related applications (moc, linguist stuff, > etc) remain either **fully** backwards compatible within the major > version *or* they are also marked with the minor. For example instead > of shipping moc6 one could ship moc6., like let's > say moc60, moc66 or alike. s/would/might/. It will still mean that distros will need to ship every LTS for at least ~4 years, or force lot of applications to get removed from their archives. We still have Qt4 around... ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 31/05/19 15:24, Volker Hilsheimer ha scritto: Hey Guiseppe, That is my understanding as well. Yes, 5.15 will be an LTS, and assumed to be the last feature release in Qt 5. Thanks for confirming my reading. I guess that the idea is that the port to Qt 6 can then happen in multiple steps: 1) port to Qt 5.latest; 2) (enable and) fix all deprecation warnings; 3) port to Qt 6. With the assumption being that “port to Qt 5.x latest” is not a huge deal, but I guess there are cases where it is not trivial either. To be honest, the real deal is 2). In this scenario that's the step which is absolutely necessary to migrate to Qt 6. (In the real world scenario, one also has to deal with other behaviour changes, e.g. the aforementioned QList). * It does not make a distinction between APIs for which we have a straightforward / immediate / scriptable (!) replacement, and APIs for which we don't (yet we'd like to get rid of them). Keeping the latter APIs as stable and supported in Qt 6.0 means keeping them since 7.0 and then face have the same problem again. But simply dropping them means pain for users. Even a scriptable migration path might only give you compilable code; the nuanced behavior of the new class you migtated to might not be identical to what your code assumes. Sorry, let me be more accurate: by scriptable I also mean that there is no behavior changes. E.g. rename QList to Qt5List, without changing anything; porting is running a search&replace. Given all the work that went into adding deprecation macros during Qt 5 lifetime (even the multiple incantations of them), would it be possible somehow to avoid most of the source breaks caused by removal of the deprecated APIs? I know that it's easier said than done, as it would require doing this on a API-by-API basis rather than turning a big switch; but we could find some compromise somewhere. Any proposal for such a “somehow” would certainly be appreciated. And source breakage is a much smaller problem than “no source breakage, but behavior is different”. The overall goal here is to make sure that we don’t have to carry poorly designed architecture or APIs around with us throughout the Qt 6 series, and as long as we care about binary and source compatibility within a major series, doing what we can for Qt 6.0 (and doing it right) is the only option we have. Perhaps we can care less about those compatilbiity promises; I personally think the "big bang every 7 years” is not giving us nearly as much as it costs; a continuous flow of carefully managed changes to either would perhaps make it rather easier for developers to follow along, and remove those big, painful porting headaches (unless you didn’t follow the Qt releases, in which case it’s just as bad as it is today). I don't have a proposal because I didn't spend time researching it. It felt like a massive exercise for little gain. As I said I don't think that there will be a "one size fits all" solution, but API by API decisions; one has to try to do some of the changes, find ways to preserve API compatibility, and then eventually come up with guidelines / coding policies employing various techniques (inline namespaces, Qt5Support library, build system tweaks, etc.). This makes the task non trivial in size. Also, I can only speak comfortably regarding the planned changes to QtCore. At this point in time I know very little about the planned changes to QtGui, QML, Qt Quick, etc.; I cannot therefore come up with a comprehensive proposal. Finally, the decision of the hard break seems to have already been made; instead of spending my energies trying to come up with a mitigation plan, I could instead spend them elsewhere, e.g.: * under the blanket cover of the "API breaks are OK in Qt 6", implement (some of) the things proposed in the other thread; * write porting documentation, augment our porting plugins for compilers, our porting scripts suite, and so on (we're the #1 independent consultancy for Qt, after all, and we do sell migrations). Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sunday, 2 June 2019 01:20:51 PDT Manuel Bergler wrote: > First of all, Qt itself > could make use of inline namespaces to ship several version of the same > classes in the same binary while keeping source compatibility. Repeat after me: inline namespaces are not a tool to retain ABI. They may allow the library to provide both ABIs. That only makes the breakage move to the next library that uses those classes. Inline namespaces are a tool for code organisation, nothing more. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sunday, 2 June 2019 07:30:11 PDT Jean-Michaël Celerier wrote: > - boost has the exact same ABI stability issue (e.g. no ABI / API stability > guarantees at all) and yet distros seem to manage all the C++ software > which uses it without much problems. Please send your distro packager some Christmas cards (or whichever holiday they celebrate) in thanking them for keeping all the pain of rebuilding the world whenever Boost or Poco change from showing to you. Again, like inline namespaces, the problem is not the library that does the upgrade. The problem shows in the next downstream library. You basically tie the entire ecosystem to a single version: if you need to upgrade one library from one Boost version to the next, you need to upgrade them all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Hi! On Sun, 2 Jun 2019 at 11:31, Jean-Michaël Celerier wrote: > > > If existing package of application cannot be rebuilt from source with > > updated > Qt version, it's a sure no-go for distibution. Either Qt update will be > blocked, or > application will be thrown away (or application will be somehow patched by > other > people, without you even knowing about that) > > - People nowadays will just use the flatpak / appimage / snap / whatever > version which will be much more up-to date than Debian Stable's Qt 5.7 (!) or > Ubuntu LTS & CentOS 's Qt 5.9 anyways. You will be amazed on the amount of people that depend upon a distibution stability and will certainly *not* use flatpaks. microelectronic CADs setup is just a tiny example of that, and I think many other examples are around. Distributions exist and don't dissapear for a reason, even if a number of people use flatpaks or whatever. > - boost has the exact same ABI stability issue (e.g. no ABI / API stability > guarantees at all) and yet distros seem to manage all the C++ software which > uses it without much problems. Boost is **exactly** the best example of why Qt should not go the same route. It's totally problematic to have more than two stacks around, and we **will** have Qt5 and Qt6 for a long time. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sun, 2 Jun 2019 at 10:10, Allan Sandfeld Jensen wrote: [snip] > > > I have no problem with breaking ABI more often but allowing it in every minor > releases probably goes to far. Perhaps every second LTS (every 3 years), might > be better. That would work as long as related applications (moc, linguist stuff, etc) remain either **fully** backwards compatible within the major version *or* they are also marked with the minor. For example instead of shipping moc6 one could ship moc6., like let's say moc60, moc66 or alike. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Hi! With my Debian maintainer hat on: On Sun, 2 Jun 2019 at 05:21, Manuel Bergler wrote: > > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler > : >> >> Volker Hilsheimer wrote: [snip] >> Your proposal to break ABI at every 6.x minor release would be an absolute >> nightmare for distributors. It would no longer be possible to upgrade stable >> releases of a distribution like Fedora to a new Qt as is frequently done >> now. Rolling-release distros would also suffer, having to go through a >> coordinated mass transition each time. And third-party PPAs upgrading Qt for >> a stable distribution would also become harder to offer (because they would >> have to rebuild ALL Qt-using packages, not just those (ab)using private >> APIs). I do not see how this would be an improvement over the current >> situation at all. Same goes for Debian, Ubuntu and (¿the vast majority?) of distros out there. > There are at least two ways Qt and/or distributors could deal with ABI > incompatible changes in minor releases of Qt 6. First of all, Qt itself could > make use of inline namespaces to ship several version of the same classes in > the same binary while keeping source compatibility. And if Qt doesn't want to > go that route because of maintenance overhead then the distributors > themselves could decide not to ship just a single version of Qt, but rather > have multiple versions side-by-side using the custom namespace and library > infix option already provided by Qt. In both cases it's a great burden. In one case in the Qt developers's shoulders (much worse that keeping API/ABI stability) and in the other in maintainers's shoulders. On the the **great** things Qt provides is actually API/ABI stability. I do understand that maybe it's not seen by many, but indeed is one of it's major strengths. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/2/19, 12:02 PM, "Stottlemyer, Brett (B.S.)" wrote: This discussion reminds me of Python 2 vs. Python 3, and I think there are some important lessons to consider from Python. FYI, I know Qt has been through version updates as well, and Qt 4 -> Qt 5 was not that long ago. For me, QML on top of OpenGL was compelling, so moving to Qt 5 was an easy choice. The Python transition, on the other hand, took a long time. So I thought the reasons for that were more pertinent to the Qt 6 discussion. Brett ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/1/19, 9:10 AM, "Development on behalf of Philippe" wrote: I second a recent quote from Lars Knoll : > Qt has always had a somewhat different philosophy. Make C++ easy to use, > no need to use Java. The fact is that 95% of the source code our users >write will not be performance critical. You dont want to make the pay >the price of having a difficult to use API for those 95% of the code. And I wish to add: the vast majority of Qt developers I have met, are not C++ wizards. Thanks Philippe/Lars, and Giuseppe for starting this separate thread. This discussion reminds me of Python 2 vs. Python 3, and I think there are some important lessons to consider from Python. I'm one of those holdouts that had a lot of Python 2 code and saw no compelling reason to move to Python 3. Until recently I didn't fully understand the reasons for the incompatible changes, so it looked like a bunch of (error prone) work with no clear value. While enum support was a nice to have, there were ways to add that to python 2. It was Python 2 nearing deprecation and some recent features (among them type safety) in Python 3 that got me to finally convert code this year. Diving into that conversion led me to a very helpful blog (from one of the core developers, Nick Coghlan) on why the changes were made in the first place: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#tl-dr-version. It is a lengthy post, so let me quote a few sections I think are particularly relevant: "[W]e did not see any other way to ensure Python remained a viable development platform as developer communities grow in locations where English is not the primary spoken language." "It is my perspective that the web and GUI developers have the right idea: dealing with Unicode text correctly is not optional in the modern world. In large part, the Python 3 redesign involved taking Unicode handling principles elaborated in those parts of the community and building them into the core design of the language." ^^^ This is the fundamental reason for the compatibility break. Three sentences! "Python 3 introduced backwards incompatible changes that more obviously helped future users of the language than they did current users, so existing users (especially library and framework developers) were being asked to devote time and effort to a transition that would cost them more in time and energy in the near term than it would save them for years to come." ^^^ This is one of the major reasons for slow adoption There is a section titled "When did Python 3 become the obvious choice for new projects?" "I put the date for this as the release of Python 3.5, in September 2015." ^^^ I believe this was the other major reason for slow adoption, a combination of two issues. There needed to be compelling features to drive the transition, and frameworks people used (numpy, nltk, twisted, etc) were slow to become available. I don't, at this point, have any idea what the right answer for Qt is. But there are three factors I think we need to consider with the move to Qt 6. 1) I believe there needs to be an elevator pitch (i.e., 30 seconds or less to tell the story) of why Qt 6 is not compatible with Qt 5 It seems like this is something along the lines of "Changes in the C++ ecosystem, specifically the compiler features added into the standards for C++11, C++14, etc, duplicate functionality provided by Qt, but in a way officially supported (and optimized) by compilers. Leveraging these features is necessary for Qt going forward, but requires incompatible changes to our APIs." I know people will disagree with the wording, if not the sentiment, here. The point is the importance of a concise reason. 2) There needs to be a reason to upgrade I remember Lars saying at QtCS last year that Qt 6 should be the easiest upgrade. It wouldn't include many new features, instead focusing on fixing the elements that couldn't be addressed without breaking compatibility; deprecation warnings in Qt 5.x would help, i.e., upgrade to 5.15, address the deprecation warnings, and viola - ready for Qt6. While I understand the ease part of that plan (and agreed it was the right approach at the time), "Upgrade to Qt 6: you may notice some performance improvements" is not a great motivator. If there isn't a clear benefit yet, then maybe something like "This was a required change in Qt, to leverage the benefits of C++11, C++14 and C++17, reduce the maintenance burden on Qt, and allow Qt to focus on bringing value to customers in other areas. New features will be coming once we've completed this transition." Side note: is it fair to say the additions in C++17, C++20, etc are becoming more esoteric, in the sense that incorporation into Qt would be less likely to be incompatible? Or should people fear Qt 7 is not too far out? 3) Be careful of "death by a thousand papercuts"
Re: [Development] Deprecation/removal model going into Qt 6
> - People nowadays will just use the flatpak / appimage / snap / whatever I can see how that works for single-binary GUI applications. Do you know any example for a complex Qt-based multi-binary (preferably command line usage) application that does that well? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
02.06.2019, 17:30, "Jean-Michaël Celerier" : >> If existing package of application cannot be rebuilt from source with >>updated > Qt version, it's a sure no-go for distibution. Either Qt update will be > blocked, or > application will be thrown away (or application will be somehow patched by > other > people, without you even knowing about that) > > - People nowadays will just use the flatpak / appimage / snap / whatever > version which will be much more up-to date than Debian Stable's Qt 5.7 (!) or > Ubuntu LTS & CentOS 's Qt 5.9 anyways. If you don't want your application to be packaged by distributions, it's your choice (there are people who do) > - boost has the exact same ABI stability issue (e.g. no ABI / API stability > guarantees at all) and yet distros seem to manage all the C++ software which > uses it without much problems. This is solved by providing side by side installations of boost. However, with Qt it won't work easily, as there are lots of libraries which use Qt types in their API -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 02/06/19 16:07, Konstantin Tokarev ha scritto: That's why I suggested using inline namespaces. Then even if an application no longer compiles with the new version of Qt it can still link against it. If existing package of application cannot be rebuilt from source with updated Qt version, it's a sure no-go for distibution. Either Qt update will be blocked, or application will be thrown away (or application will be somehow patched by other people, without you even knowing about that) But this is a problem for Qt only in the sense that API breaks (if any) / deprecations / etc. need to come at a not-too-fast pace. Or what you're describing is an unmaintained application, which then rightfully should get dropped by distributions. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> If existing package of application cannot be rebuilt from source with updated Qt version, it's a sure no-go for distibution. Either Qt update will be blocked, or application will be thrown away (or application will be somehow patched by other people, without you even knowing about that) - People nowadays will just use the flatpak / appimage / snap / whatever version which will be much more up-to date than Debian Stable's Qt 5.7 (!) or Ubuntu LTS & CentOS 's Qt 5.9 anyways. - boost has the exact same ABI stability issue (e.g. no ABI / API stability guarantees at all) and yet distros seem to manage all the C++ software which uses it without much problems. My 0.02€ Jean-Michaël On Sun, Jun 2, 2019 at 4:08 PM Konstantin Tokarev wrote: > > > 02.06.2019, 17:03, "Manuel Bergler" : > > Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev > > : > >> 02.06.2019, 16:34, "Manuel Bergler" : > >> > Due to Hyrum's law [0], even with stricter guarantees there will > >> > always be someone for which migration is a non-trivial amount of > work. > >> > The only way to avoid that is to change nothing, ever. I personally > >> > also don't understand why people would expect getting shiny new > >> > features of a new minor release without having to pay a cost of > >> > migrating their code over. I believe that as long as the benefit of > >> > the new features outweighs the cost of migration then people will be > >> > willing to migrate anyway. I myself don't mind the 2 weeks it took so > >> > far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the > >> > cost of progress... > >> > >> In open source world Qt version is not easily chosen by developer. > >> If Qt updates are source-incompatible, distributions will stuck with > old Qt > >> as long as possible to avoid massive breakages, and if new version of > your > >> app requeres newer Qt than what is shipped by distribution, users will > get > >> older version which is still compatible. > > > > That's why I suggested using inline namespaces. Then even if an > > application no longer compiles with the new version of Qt it can still > > link against it. > > If existing package of application cannot be rebuilt from source with > updated > Qt version, it's a sure no-go for distibution. Either Qt update will be > blocked, or > application will be thrown away (or application will be somehow patched by > other > people, without you even knowing about that) > > -- > Regards, > Konstantin > > ___ > 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
Re: [Development] Deprecation/removal model going into Qt 6
02.06.2019, 17:03, "Manuel Bergler" : > Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev > : >> 02.06.2019, 16:34, "Manuel Bergler" : >> > Due to Hyrum's law [0], even with stricter guarantees there will >> > always be someone for which migration is a non-trivial amount of work. >> > The only way to avoid that is to change nothing, ever. I personally >> > also don't understand why people would expect getting shiny new >> > features of a new minor release without having to pay a cost of >> > migrating their code over. I believe that as long as the benefit of >> > the new features outweighs the cost of migration then people will be >> > willing to migrate anyway. I myself don't mind the 2 weeks it took so >> > far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the >> > cost of progress... >> >> In open source world Qt version is not easily chosen by developer. >> If Qt updates are source-incompatible, distributions will stuck with old Qt >> as long as possible to avoid massive breakages, and if new version of your >> app requeres newer Qt than what is shipped by distribution, users will get >> older version which is still compatible. > > That's why I suggested using inline namespaces. Then even if an > application no longer compiles with the new version of Qt it can still > link against it. If existing package of application cannot be rebuilt from source with updated Qt version, it's a sure no-go for distibution. Either Qt update will be blocked, or application will be thrown away (or application will be somehow patched by other people, without you even knowing about that) -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev : > > > > 02.06.2019, 16:34, "Manuel Bergler" : > > Due to Hyrum's law [0], even with stricter guarantees there will > > always be someone for which migration is a non-trivial amount of work. > > The only way to avoid that is to change nothing, ever. I personally > > also don't understand why people would expect getting shiny new > > features of a new minor release without having to pay a cost of > > migrating their code over. I believe that as long as the benefit of > > the new features outweighs the cost of migration then people will be > > willing to migrate anyway. I myself don't mind the 2 weeks it took so > > far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the > > cost of progress... > > In open source world Qt version is not easily chosen by developer. > If Qt updates are source-incompatible, distributions will stuck with old Qt > as long as possible to avoid massive breakages, and if new version of your > app requeres newer Qt than what is shipped by distribution, users will get > older version which is still compatible. That's why I suggested using inline namespaces. Then even if an application no longer compiles with the new version of Qt it can still link against it. Thus, distributions can freely update Qt without breaking any client packages, they just need to ship what they shipped before and it'll just work*. Or are you saying that distributions would still not update Qt because they might break code that their users wrote that isn't part of the distributions package repository? In that case distributions can still choose to ship different versions of Qt side-by-side as I suggested earlier, most distributions already do that for Qt4 and Qt5. Best Manuel * at least just as good as it "works" right now, i.e. ignoring silent behavior changes ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
02.06.2019, 16:34, "Manuel Bergler" : > Due to Hyrum's law [0], even with stricter guarantees there will > always be someone for which migration is a non-trivial amount of work. > The only way to avoid that is to change nothing, ever. I personally > also don't understand why people would expect getting shiny new > features of a new minor release without having to pay a cost of > migrating their code over. I believe that as long as the benefit of > the new features outweighs the cost of migration then people will be > willing to migrate anyway. I myself don't mind the 2 weeks it took so > far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the > cost of progress... In open source world Qt version is not easily chosen by developer. If Qt updates are source-incompatible, distributions will stuck with old Qt as long as possible to avoid massive breakages, and if new version of your app requeres newer Qt than what is shipped by distribution, users will get older version which is still compatible. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> Manuel Bergler wrote: > > Right now, even though the API and ABI are stable, I have never seen an > > update to a new minor version of Qt5 that did not require source changes > > due to changed behavior, > > Well, that depends pretty much on the individual project (how large it is > and what parts of Qt it uses). Some projects indeed keep having to be fixed > regularly, others just work unchanged throughout all of Qt 5.x. (In some > extreme cases, even moving from Qt 4 to Qt 5 did not require any changes > outside of the build system.) > > As far as I can tell (I was a Qt comaintainer in Fedora for years and I am > still involved in Fedora packaging and in IRC contact with the current Qt > maintainers), the Fedora Qt packagers' experience is that bumping to a new > 5.x branch usually only requires rebuilding (usually without source changes) > the known abusers of private APIs, and then occasionally fixing a handful > packages that get reported to us (either by users encountering regressions > or by the upstreams themselves warning all distributors), but most packages > keep working without even a rebuild. Only occasionally, there were Qt bumps > that caused enough issues to withhold them from stable release updates. My experience here is rather limited, so far I've only worked on two commercial Qt projects at two different companies. Both did not use private APIs and yet upgrading took at least a few days, sometimes even several weeks and always required source changes. > > > > so fixing a few calls that no longer compile doesn't increase the cost of > > updating all that much. As a matter of fact, fixing source > > incompatibilities is in my experience much easier than figuring out why > > behavior has changed, since I don't even have a starting point where to > > look in the latter case. > > But that is pretty much an argument for even stricter compatibility > guarantees, also forbidding at least some behavior changes. (I understand > that sometimes, fixing a bug or even a security issue requires a change in > behavior, but it should be avoided.) Laxer compatibility rules will just > make it worse, because the behavior changes will not disappear without a > rule banning them, you will just have to fix source incompatibilities in > addition. Due to Hyrum's law [0], even with stricter guarantees there will always be someone for which migration is a non-trivial amount of work. The only way to avoid that is to change nothing, ever. I personally also don't understand why people would expect getting shiny new features of a new minor release without having to pay a cost of migrating their code over. I believe that as long as the benefit of the new features outweighs the cost of migration then people will be willing to migrate anyway. I myself don't mind the 2 weeks it took so far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the cost of progress... However, since the cost of migration needs to be lower than the benefit of the new features, there are some consequences: - Obviously, just because API breaks are allowed they still shouldn't happen without good justification, e.g. only because an API proved to be to easy to use incorrectly or to hard to use correctly - Make hard to find behavior changes API breaking instead, so that the compiler helps with the migration. - Use inline namespaces so that old binaries will still run with the new version of Qt and ABI incompatible libraries build with different Qt versions fail to link instead of leading to seemingly random runtime crashes. Best Manuel [0] http://www.hyrumslaw.com/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 01/06/19 23:34, Kevin Kofler ha scritto: Volker Hilsheimer wrote: The overall goal here is to make sure that we don’t have to carry poorly designed architecture or APIs around with us throughout the Qt 6 series, and as long as we care about binary and source compatibility within a major series, doing what we can for Qt 6.0 (and doing it right) is the only option we have. Perhaps we can care less about those compatilbiity promises; I personally think the "big bang every 7 years” is not giving us nearly as much as it costs; a continuous flow of carefully managed changes to either would perhaps make it rather easier for developers to follow along, and remove those big, painful porting headaches (unless you didn’t follow the Qt releases, in which case it’s just as bad as it is today). But the problem for developers is NOT the 5.x releases that do not break the API. Those are great! The problem is those n.0 releases that DO break the API. And the solution there would be to just stop doing this kind of releases. But this is simply impossible. It would require an infinite development bandwidth, and at a certain point, may constrain development too much. Ballast (obsolete functionality, for various degree of "obsolete") has to be dropped from time to time, causing API breaks. The question in this thread is how to manage those API breaks to be as painless as possible. Changes such as deprecating or incompatibly rewriting a data structure as central as QList (as seems to be already consensus for Qt 6) are just a major disservice to developers. ... exactly, because it's an API break. How can we minimize the damage? ABI breaks such as the QString SSO (that also seems to be already consensus for Qt 6) are also unnecessary and probably also counterproductive in some use cases. What? Why? Your proposal to break ABI at every 6.x minor release would be an absolute nightmare for distributors. I personally interpreted "continuous flow of carefully managed changes" as "small" API breaks, not (just) ABI breaks. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sonntag, 2. Juni 2019 10:20:51 CEST Manuel Bergler wrote: > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler < > > kevin.kof...@chello.at>: > > Volker Hilsheimer wrote: > > > The overall goal here is to make sure that we don’t have to carry poorly > > > designed architecture or APIs around with us throughout the Qt 6 series, > > > and as long as we care about binary and source compatibility within a > > > major series, doing what we can for Qt 6.0 (and doing it right) is the > > > only option we have. > > > > > > Perhaps we can care less about those compatilbiity promises; I > > > personally > > > think the "big bang every 7 years” is not giving us nearly as much as it > > > costs; a continuous flow of carefully managed changes to either would > > > perhaps make it rather easier for developers to follow along, and remove > > > those big, painful porting headaches (unless you didn’t follow the Qt > > > releases, in which case it’s just as bad as it is today). > > > > But the problem for developers is NOT the 5.x releases that do not break > > the > > API. Those are great! The problem is those n.0 releases that DO break the > > API. And the solution there would be to just stop doing this kind of > > releases. Changes such as deprecating or incompatibly rewriting a data > > structure as central as QList (as seems to be already consensus for Qt 6) > > are just a major disservice to developers. ABI breaks such as the QString > > SSO (that also seems to be already consensus for Qt 6) are also > > unnecessary > > and probably also counterproductive in some use cases. And switching the > > build system for Qt itself to CMake, while still supporting both CMake and > > QMake for user code (as Qt 5 with its QMake-based build system already > > does), can be done without breaking source nor binary compatibility. > > > > Your proposal to break ABI at every 6.x minor release would be an absolute > > nightmare for distributors. It would no longer be possible to upgrade > > stable > > releases of a distribution like Fedora to a new Qt as is frequently done > > now. Rolling-release distros would also suffer, having to go through a > > coordinated mass transition each time. And third-party PPAs upgrading Qt > > for > > a stable distribution would also become harder to offer (because they > > would > > have to rebuild ALL Qt-using packages, not just those (ab)using private > > APIs). I do not see how this would be an improvement over the current > > situation at all. > > > > Kevin Kofler > > There are at least two ways Qt and/or distributors could deal with ABI > incompatible changes in minor releases of Qt 6. First of all, Qt itself > could make use of inline namespaces to ship several version of the same > classes in the same binary while keeping source compatibility. And if Qt > doesn't want to go that route because of maintenance overhead then the > distributors themselves could decide not to ship just a single version of > Qt, but rather have multiple versions side-by-side using the custom > namespace and library infix option already provided by Qt. > > That said, I'm in favor of allowing ABI (and in my opinion even API) > breaking changes in minor releases, since that allows to evolve APIs > continuously instead of only once every major release. Right now, even > though the API and ABI are stable, I have never seen an update to a new > minor version of Qt5 that did not require source changes due to changed > behavior, so fixing a few calls that no longer compile doesn't increase the > cost of updating all that much. As a matter of fact, fixing source > incompatibilities is in my experience much easier than figuring out why > behavior has changed, since I don't even have a starting point where to > look in the latter case. > I have no problem with breaking ABI more often but allowing it in every minor releases probably goes to far. Perhaps every second LTS (every 3 years), might be better. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> On 1 Jun 2019, at 16:12, Alberto Mardegan wrote: > > On 5/31/19 4:24 PM, Volker Hilsheimer wrote: >> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with >> three years maintenance. We are not expecting lots of people to jump >> on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when >> an API was marked as deprecated makes perhaps not that much >> difference “in real time”. > > Three years is not a lot of time when moving between major releases. It > would be nice if the last LTS release in a major release series were > supported for a longer time (5 years?). > > Ciao, > Alberto How long did it take y’all to move from Qt 4.x to Qt 5.x? The move from Qt 2 to Qt 3, and from Qt 3 to Qt 4, is brought up as examples of bad experiences (but then let’s also consider how terrible Qt would be today if we would still have to drag Qt 2 or Qt 3 concepts around with us). But if the goal for Qt 6 is to be rather comparable to the Qt 4 to Qt 5, how bad would it be? Of course, milage will vary depending on the nature and size of your codebase, and I’m sure my colleagues in The Qt Company sales would be happy to discuss support options, when the time comes. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 01/06/19 23:17, Kevin Kofler ha scritto: Indeed. One case in point: All this confabulation about move constructors etc. misses the point that the gain of moving compared to shallow copying with CoW is typically irrelevant for those 95% of non-performance-critical code. But using explicit move semantics correctly is significantly harder and more prone to misuse than using Qt's implicit CoW. Please, let's try to stay on topic; bring these considerations to _that_ thread. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Manuel Bergler wrote: > Right now, even though the API and ABI are stable, I have never seen an > update to a new minor version of Qt5 that did not require source changes > due to changed behavior, Well, that depends pretty much on the individual project (how large it is and what parts of Qt it uses). Some projects indeed keep having to be fixed regularly, others just work unchanged throughout all of Qt 5.x. (In some extreme cases, even moving from Qt 4 to Qt 5 did not require any changes outside of the build system.) As far as I can tell (I was a Qt comaintainer in Fedora for years and I am still involved in Fedora packaging and in IRC contact with the current Qt maintainers), the Fedora Qt packagers' experience is that bumping to a new 5.x branch usually only requires rebuilding (usually without source changes) the known abusers of private APIs, and then occasionally fixing a handful packages that get reported to us (either by users encountering regressions or by the upstreams themselves warning all distributors), but most packages keep working without even a rebuild. Only occasionally, there were Qt bumps that caused enough issues to withhold them from stable release updates. > so fixing a few calls that no longer compile doesn't increase the cost of > updating all that much. As a matter of fact, fixing source > incompatibilities is in my experience much easier than figuring out why > behavior has changed, since I don't even have a starting point where to > look in the latter case. But that is pretty much an argument for even stricter compatibility guarantees, also forbidding at least some behavior changes. (I understand that sometimes, fixing a bug or even a security issue requires a change in behavior, but it should be avoided.) Laxer compatibility rules will just make it worse, because the behavior changes will not disappear without a rule banning them, you will just have to fix source incompatibilities in addition. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler < kevin.kof...@chello.at>: > Volker Hilsheimer wrote: > > The overall goal here is to make sure that we don’t have to carry poorly > > designed architecture or APIs around with us throughout the Qt 6 series, > > and as long as we care about binary and source compatibility within a > > major series, doing what we can for Qt 6.0 (and doing it right) is the > > only option we have. > > > > Perhaps we can care less about those compatilbiity promises; I personally > > think the "big bang every 7 years” is not giving us nearly as much as it > > costs; a continuous flow of carefully managed changes to either would > > perhaps make it rather easier for developers to follow along, and remove > > those big, painful porting headaches (unless you didn’t follow the Qt > > releases, in which case it’s just as bad as it is today). > > But the problem for developers is NOT the 5.x releases that do not break > the > API. Those are great! The problem is those n.0 releases that DO break the > API. And the solution there would be to just stop doing this kind of > releases. Changes such as deprecating or incompatibly rewriting a data > structure as central as QList (as seems to be already consensus for Qt 6) > are just a major disservice to developers. ABI breaks such as the QString > SSO (that also seems to be already consensus for Qt 6) are also > unnecessary > and probably also counterproductive in some use cases. And switching the > build system for Qt itself to CMake, while still supporting both CMake and > QMake for user code (as Qt 5 with its QMake-based build system already > does), can be done without breaking source nor binary compatibility. > > Your proposal to break ABI at every 6.x minor release would be an absolute > nightmare for distributors. It would no longer be possible to upgrade > stable > releases of a distribution like Fedora to a new Qt as is frequently done > now. Rolling-release distros would also suffer, having to go through a > coordinated mass transition each time. And third-party PPAs upgrading Qt > for > a stable distribution would also become harder to offer (because they > would > have to rebuild ALL Qt-using packages, not just those (ab)using private > APIs). I do not see how this would be an improvement over the current > situation at all. > > Kevin Kofler > > There are at least two ways Qt and/or distributors could deal with ABI incompatible changes in minor releases of Qt 6. First of all, Qt itself could make use of inline namespaces to ship several version of the same classes in the same binary while keeping source compatibility. And if Qt doesn't want to go that route because of maintenance overhead then the distributors themselves could decide not to ship just a single version of Qt, but rather have multiple versions side-by-side using the custom namespace and library infix option already provided by Qt. That said, I'm in favor of allowing ABI (and in my opinion even API) breaking changes in minor releases, since that allows to evolve APIs continuously instead of only once every major release. Right now, even though the API and ABI are stable, I have never seen an update to a new minor version of Qt5 that did not require source changes due to changed behavior, so fixing a few calls that no longer compile doesn't increase the cost of updating all that much. As a matter of fact, fixing source incompatibilities is in my experience much easier than figuring out why behavior has changed, since I don't even have a starting point where to look in the latter case. Best Manuel ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Volker Hilsheimer wrote: > The overall goal here is to make sure that we don’t have to carry poorly > designed architecture or APIs around with us throughout the Qt 6 series, > and as long as we care about binary and source compatibility within a > major series, doing what we can for Qt 6.0 (and doing it right) is the > only option we have. > > Perhaps we can care less about those compatilbiity promises; I personally > think the "big bang every 7 years” is not giving us nearly as much as it > costs; a continuous flow of carefully managed changes to either would > perhaps make it rather easier for developers to follow along, and remove > those big, painful porting headaches (unless you didn’t follow the Qt > releases, in which case it’s just as bad as it is today). But the problem for developers is NOT the 5.x releases that do not break the API. Those are great! The problem is those n.0 releases that DO break the API. And the solution there would be to just stop doing this kind of releases. Changes such as deprecating or incompatibly rewriting a data structure as central as QList (as seems to be already consensus for Qt 6) are just a major disservice to developers. ABI breaks such as the QString SSO (that also seems to be already consensus for Qt 6) are also unnecessary and probably also counterproductive in some use cases. And switching the build system for Qt itself to CMake, while still supporting both CMake and QMake for user code (as Qt 5 with its QMake-based build system already does), can be done without breaking source nor binary compatibility. Your proposal to break ABI at every 6.x minor release would be an absolute nightmare for distributors. It would no longer be possible to upgrade stable releases of a distribution like Fedora to a new Qt as is frequently done now. Rolling-release distros would also suffer, having to go through a coordinated mass transition each time. And third-party PPAs upgrading Qt for a stable distribution would also become harder to offer (because they would have to rebuild ALL Qt-using packages, not just those (ab)using private APIs). I do not see how this would be an improvement over the current situation at all. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Philippe wrote: > On Sat, 1 Jun 2019 14:36:12 +0200 > André Pönitz wrote: > >> So it might make even sense to step back further and start with >> asking "What should Qt be?" before trying to find out on whether >> a specific API is poorly designed or not, as that decision depends >> on the purpose. > > I second a recent quote from Lars Knoll : > >> Qt has always had a somewhat different philosophy. Make C++ easy to use, >> no need to use Java. The fact is that 95% of the source code our users >> write will not be performance critical. You don't want to make the pay >> the price of having a difficult to use API for those 95% of the code. > > And I wish to add: the vast majority of Qt developers I have met, are > not C++ wizards. Indeed. One case in point: All this confabulation about move constructors etc. misses the point that the gain of moving compared to shallow copying with CoW is typically irrelevant for those 95% of non-performance-critical code. But using explicit move semantics correctly is significantly harder and more prone to misuse than using Qt's implicit CoW. To avoid a deep copy STL-style, you have to use std::move explicitly. To avoid the deep copy Qt-style, you just assign the Qt container and it will automatically be just a shallow copy. And the Qt idiom is more flexible because it does not force you to invalidate the original reference. (That said, at least there *is* a way to avoid the deep copy in STL now. In C++98, e.g., returning an STL container from a function was just a no-go.) And yes, I know that there are corner cases where std::move can help on CoW types, saving some atomic operations, or even avoiding a detach because the old reference was invalidated by std::move. But I still would NOT call incomplete implementation of move semantics a showstopper in a CoW data structure API (unlike some of the self-proclaimed "C++ wizards" here). Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 5/31/19 4:24 PM, Volker Hilsheimer wrote: > Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with > three years maintenance. We are not expecting lots of people to jump > on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when > an API was marked as deprecated makes perhaps not that much > difference “in real time”. Three years is not a lot of time when moving between major releases. It would be nice if the last LTS release in a major release series were supported for a longer time (5 years?). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sat, 1 Jun 2019 14:36:12 +0200 André Pönitz wrote: > So it might make even sense to step back further and start with > asking "What should Qt be?" before trying to find out on whether > a specific API is poorly designed or not, as that decision depends > on the purpose. I second a recent quote from Lars Knoll : > Qt has always had a somewhat different philosophy. Make C++ easy to use, > no need to use Java. The fact is that 95% of the source code our users >write will not be performance critical. You dont want to make the pay >the price of having a difficult to use API for those 95% of the code. And I wish to add: the vast majority of Qt developers I have met, are not C++ wizards. Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote:
> The overall goal here is to make sure that we don’t have to carry
> poorly designed architecture or APIs around with us throughout the Qt
> 6 series, and as long as we care about binary and source compatibility
> within a major series, doing what we can for Qt 6.0 (and doing it
> right) is the only option we have.
The problem is that we as a whole do not agree what "poorly designed
architecture or APIs" means in detail anymore, sometimes even on a very
fundamental level.
E.g. the previous consent on Qt providing consistency and convenience
is challenged regularly by some.
So it might make even sense to step back further and start with
asking "What should Qt be?" before trying to find out on whether
a specific API is poorly designed or not, as that decision depends
on the purpose.
> Perhaps we can care less about those compatilbiity promises; I
> personally think the "big bang every 7 years” is not giving us nearly
> as much as it costs; a continuous flow of carefully managed changes to
> either would perhaps make it rather easier for developers to follow
> along, and remove those big, painful porting headaches (unless you
> didn’t follow the Qt releases, in which case it’s just as bad as it is
> today).
That sounds actually good. I also see people more likely investing
in gradual "keeping up" efforts than in big rewrites every seventh
year.
And yes, weakening the compatibility promises is a possibility.
I've been arguing for ages that it does not make sense to have
BC and SC guarantees on int forty_two() { return 42; } that
allow changing that to int forty_two() { return 43; }.
Being allowed to add a int forty_three() { return 43; } if that's
more useful than forty_two in practice and deprecating/even removing
forty_two a while later makes more sense to me.
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Fri, May 31, 2019 at 02:50:45PM +0200, Giuseppe D'Angelo via Development wrote: > I guess that the idea is that the port to Qt 6 can then happen in multiple > steps: > > 1) port to Qt 5.latest; > 2) (enable and) fix all deprecation warnings; > 3) port to Qt 6. > If this is still the plan, I must say I am not a huge fan of it. It has all > the premises to be another Qt3->4 hit. Specifically: It was never *my* plan, and the plan listed here has exactly the problems you mentioned. > * It assumes that any breaking change will happen in Qt 5 first, > signalled via deprecation macros, then Qt 6 will simply remove the > deprecated parts. As we're already seeing with e.g. QList, this is > not happening for all the possible cases, meaning the porting steps > above are incomplete and there will be some extra porting fallout to > take into account. > > * It does not let users move away at their own pace. Qt 6.0 will be > inaccessible for existing Qt 5 software until one has ported away from > every deprecated API. If we keep deprecating things (and add > replacements) up to 5.latest, then this also makes it complicated for > users to build libraries and components targeting both Qt 5 and 6. > > Such libraries may end up to only be able to target Qt 5.latest and 6 > together, without resorting to #ifdefs or similar machinery in their > code; the reason is that only 5.latest would have the required > replacement APIs for the ones deprecated in 5.latest / removed from > 6.0. > > * It does not make a distinction w.r.t. _when_ an API has been > deprecated. IMHO there is a difference between an API deprecated in > 5.0 and one deprecated in 5.15; users had much more time to port away > from the former. Dropping them both on the floor in 6.0 seems very > unfair to me, again forcing users to tackle the deprecation > _immediately_ if they want to port to Qt 6. > > * It does not make a distinction between APIs for which we have a > straightforward / immediate / scriptable (!) replacement, and APIs for > which we don't (yet we'd like to get rid of them). Keeping the latter > APIs as stable and supported in Qt 6.0 means keeping them since 7.0 > and then face have the same problem again. But simply dropping them > means pain for users. > > Given all the work that went into adding deprecation macros during Qt > 5 lifetime (even the multiple incantations of them), would it be > possible somehow to avoid most of the source breaks caused by removal > of the deprecated APIs? I know that it's easier said than done, as it > would require doing this on a API-by-API basis rather than turning a > big switch; but we could find some compromise somewhere. I think the compromise is API-by-API deprecation, with a grace period for each one (>= 1 LTS cycle) between the availability of a serious alternative for that API and the deprectation marking of the old version. And with "serious" I mean something not contested, i.e. nothing based on "there's a boost library doing something similar" or "I do not use this API, so nobody else should use it either". In all other setups it is practically impossible to use deprecation warnings as errors. > Anyhow, flame away. I see no reason for flames here, I fully agree with what you wrote. If there's no transitional phase where a codebase can be reasonably easy be compiled with Qt 5 and Qt 6 we'll end up in a situation where staying with Qt 5 for eternity will be the prefered solution for some. We need to take into account that a lot of code is still written in a way that only schedules resources for creation, but not for active maintenance. Usually some life support happens "for free", but real porting cannot be done in such circumstances. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Hey Guiseppe, > On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development > wrote: > > Hi, > > It seems to me that many emails in the earlier deprecation thread were from > users concerned by the problem of removal of functionality. This is not an > old story. > > However, apart from the specifics of why deprecating a certain class / what > to replace it with / etc., there's a bigger thing that needs to be clarified, > which is: what is the deprecation/removal model going into Qt 6. > > > It is my understanding that the current plan is to: > > * _remove_ from Qt 6.0 any API deprecated in Qt 5.x (for any x); > > * in order to ease the migration from Qt 5, any API that is going to be > removed/changed in Qt 6.0 (for any reason) is also going to be deprecated in > Qt 5.latest (5.15 LTS, AFAIU). That is my understanding as well. Yes, 5.15 will be an LTS, and assumed to be the last feature release in Qt 5. > I guess that the idea is that the port to Qt 6 can then happen in multiple > steps: > > 1) port to Qt 5.latest; > 2) (enable and) fix all deprecation warnings; > 3) port to Qt 6. With the assumption being that “port to Qt 5.x latest” is not a huge deal, but I guess there are cases where it is not trivial either. > If this is still the plan, I must say I am not a huge fan of it. It has all > the premises to be another Qt3->4 hit. Specifically: > > * It assumes that any breaking change will happen in Qt 5 first, signalled > via deprecation macros, then Qt 6 will simply remove the deprecated parts. As > we're already seeing with e.g. QList, this is not happening for all the > possible cases, meaning the porting steps above are incomplete and there will > be some extra porting fallout to take into account. Thinking about all cases and situations is usually hard, often impossible; that fact doesn’t change by moving to a different way of deprecating and removing stuff. Some people will have used things in a way that nobody anticipated, and they will have less fun than others. > * It does not let users move away at their own pace. Qt 6.0 will be > inaccessible for existing Qt 5 software until one has ported away from every > deprecated API. If we keep deprecating things (and add replacements) up to > 5.latest, then this also makes it complicated for users to build libraries > and components targeting both Qt 5 and 6. Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with three years maintenance. We are not expecting lots of people to jump on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when an API was marked as deprecated makes perhaps not that much difference “in real time”. > Such libraries may end up to only be able to target Qt 5.latest and 6 > together, without resorting to #ifdefs or similar machinery in their code; > the reason is that only 5.latest would have the required replacement APIs for > the ones deprecated in 5.latest / removed from 6.0. > > * It does not make a distinction w.r.t. _when_ an API has been deprecated. > IMHO there is a difference between an API deprecated in 5.0 and one > deprecated in 5.15; users had much more time to port away from the former. > Dropping them both on the floor in 6.0 seems very unfair to me, again forcing > users to tackle the deprecation _immediately_ if they want to port to Qt 6. > > * It does not make a distinction between APIs for which we have a > straightforward / immediate / scriptable (!) replacement, and APIs for which > we don't (yet we'd like to get rid of them). Keeping the latter APIs as > stable and supported in Qt 6.0 means keeping them since 7.0 and then face > have the same problem again. But simply dropping them means pain for users. Even a scriptable migration path might only give you compilable code; the nuanced behavior of the new class you migtated to might not be identical to what your code assumes. > Given all the work that went into adding deprecation macros during Qt 5 > lifetime (even the multiple incantations of them), would it be possible > somehow to avoid most of the source breaks caused by removal of the > deprecated APIs? I know that it's easier said than done, as it would require > doing this on a API-by-API basis rather than turning a big switch; but we > could find some compromise somewhere. Any proposal for such a “somehow” would certainly be appreciated. And source breakage is a much smaller problem than “no source breakage, but behavior is different”. The overall goal here is to make sure that we don’t have to carry poorly designed architecture or APIs around with us throughout the Qt 6 series, and as long as we care about binary and source compatibility within a major series, doing what we can for Qt 6.0 (and doing it right) is the only option we have. Perhaps we can care less about those compatilbiity promises; I personally think the "big bang every 7 years” is not giving us nearly as much as it costs; a conti
[Development] Deprecation/removal model going into Qt 6
Hi, It seems to me that many emails in the earlier deprecation thread were from users concerned by the problem of removal of functionality. This is not an old story. However, apart from the specifics of why deprecating a certain class / what to replace it with / etc., there's a bigger thing that needs to be clarified, which is: what is the deprecation/removal model going into Qt 6. It is my understanding that the current plan is to: * _remove_ from Qt 6.0 any API deprecated in Qt 5.x (for any x); * in order to ease the migration from Qt 5, any API that is going to be removed/changed in Qt 6.0 (for any reason) is also going to be deprecated in Qt 5.latest (5.15 LTS, AFAIU). I guess that the idea is that the port to Qt 6 can then happen in multiple steps: 1) port to Qt 5.latest; 2) (enable and) fix all deprecation warnings; 3) port to Qt 6. If this is still the plan, I must say I am not a huge fan of it. It has all the premises to be another Qt3->4 hit. Specifically: * It assumes that any breaking change will happen in Qt 5 first, signalled via deprecation macros, then Qt 6 will simply remove the deprecated parts. As we're already seeing with e.g. QList, this is not happening for all the possible cases, meaning the porting steps above are incomplete and there will be some extra porting fallout to take into account. * It does not let users move away at their own pace. Qt 6.0 will be inaccessible for existing Qt 5 software until one has ported away from every deprecated API. If we keep deprecating things (and add replacements) up to 5.latest, then this also makes it complicated for users to build libraries and components targeting both Qt 5 and 6. Such libraries may end up to only be able to target Qt 5.latest and 6 together, without resorting to #ifdefs or similar machinery in their code; the reason is that only 5.latest would have the required replacement APIs for the ones deprecated in 5.latest / removed from 6.0. * It does not make a distinction w.r.t. _when_ an API has been deprecated. IMHO there is a difference between an API deprecated in 5.0 and one deprecated in 5.15; users had much more time to port away from the former. Dropping them both on the floor in 6.0 seems very unfair to me, again forcing users to tackle the deprecation _immediately_ if they want to port to Qt 6. * It does not make a distinction between APIs for which we have a straightforward / immediate / scriptable (!) replacement, and APIs for which we don't (yet we'd like to get rid of them). Keeping the latter APIs as stable and supported in Qt 6.0 means keeping them since 7.0 and then face have the same problem again. But simply dropping them means pain for users. Given all the work that went into adding deprecation macros during Qt 5 lifetime (even the multiple incantations of them), would it be possible somehow to avoid most of the source breaks caused by removal of the deprecated APIs? I know that it's easier said than done, as it would require doing this on a API-by-API basis rather than turning a big switch; but we could find some compromise somewhere. Anyhow, flame away. Thanks for reading, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
