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] Qt 5 types under consideration for deprecation / removal in Qt 6
On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: > I also managed to get that done with a <10 lines of "plain cmake": > > https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05 > 7/src/CMakeLists.txt#L46-L54 Yup, I figured with CMake it would be possible. But I'm trying to get this in Qt 5 first. -- 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] Qt 5 types under consideration for deprecation / removal in Qt 6
On 01.06.19 17:56, Thiago Macieira wrote: On Saturday, 1 June 2019 03:46:34 PDT André Pönitz wrote: I am getting mildly irritated by those ongoing suggestions (not just yours) to use anything but Qt to get stuff done, even Qt's own tasks. It's sending an odd message. Sure, one can pull e.g. any "plain C++" replacement for QXmlStreamReader for rcc. With the usual non-Qt approaches this means either some other 3rd party dependency or some ad-hoc implementation providing the part of XML parsing rcc actually needs, or to switch over to another .qrc format. At the end of the day, all that would be doable, but *why*? I'm not suggesting we drop the Qt code from those tools. I'm suggesting that we un-bootstrap them after we make QtCore not require them at all. If I can get powershell to produce a C-consumable hex dump of the file, we can get rid of rcc as a QtCore dependency. But rcc as a tool remains. I also managed to get that done with a <10 lines of "plain cmake": https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb057/src/CMakeLists.txt#L46-L54 ___ 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] QList for Qt 6
I'm a bit late to this game, but ... > I don’t see why you’d want to remove the switch for Qt 6. > It would be a porting help for application developers. Application developers will not build their own Qt, but rely on the QList with the switch their Qt and Qt-using 3rd party libraries are built with. And how does it work if different 3rdparty qt libraries requires the switch differently? /Sune - Qt, KDE and Debian guy at night. Qt & c++ freelancer by day. ___ I can tell you from m Qt3 -> Qt4 transition, with a similar switch (to enable Qt3 functions that were killed off) We did the following.. Our release, was built with the Qt3to4 library and switches enabled. However, our developer builds had the switch turned off, so we didn’t introduce new code using the old API. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On 2019-05-23, Lars Knoll wrote: I'm a bit late to this game, but ... > I don’t see why you’d want to remove the switch for Qt 6. > It would be a porting help for application developers. Application developers will not build their own Qt, but rely on the QList with the switch their Qt and Qt-using 3rd party libraries are built with. And how does it work if different 3rdparty qt libraries requires the switch differently? /Sune - Qt, KDE and Debian guy at night. Qt & c++ freelancer by day. ___ 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
