On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote: > Thiago, you partially implying that BC is still needed but with > technologies like flatpak or snappy this will maybe not common use > case anymore. They provide even behaviour compatibility if you stay with the > same runtime. > Something which is not provided by binary compability. I personally > think if the behaviour is changed it should not even compile anymore > so you can fix it easily.
Some level of compatibility is of course required, unless you're proposing we provide a certain level of bugfixing for ALL releases for a number of years. That is, if 6.2 isn't source-compatible with 6.1, then 6.1 needs to be supported for 3+ years with bugfixes for code that was ported to 6.1 but hasn't been ported further to 6.2. If we're still keeping source compatibility but not binary, the problem is not as big as above. But it still exists if you're not in a position to recompile all modules (think third party's component). -- Im just going to throw out my 2 bits on this.... Please don’t underestimate (and Im not hearing Thiago say this) the pain, of breaking source compatibility. Even on Major (5->6) version changes. Qt lost a lot of momentum, but eventually gained it back, in the 3-4 transition. And it was more than just "the code didn’t compile" it was also, lost functionality that was take from 3, a hack added in 4.1 (missing in 4.0 IIRC) and then fully replaced in 4.4.. And Im talking about the Graphics Scene/View... We have a similar issue, even if it has been 2-3 years already, with the change in web viewer... I know of more than one project, including my product, that is stuck on an old version of Qt, simply because the new web view, is missing some functionality. And building the old browser classes is a less than "wonderful" solution. When the Qt team, decides to make these changes, it hurts a lot of developers, who have to justify to their company, I need to spend X number of months figuring out a solution, to replicate code that was already working fine... From a utopic point of view, Id be fine with, if every Qt container, and class that has been "mostly" implemented in STL, or the native language was thrown out.. But as I tell my employees, just because its in the language now, doesn’t mean we should go through our 2.5 million lines of code, and re-write every one to use modern C++... To replace out every container, that works today? And in the process, break probably billions of lines of existing Qt code, which would have to be re-written using the new containers??? Please don’t.... Even for 6.0... Some form of transition would be great. Maybe, line in the Qt3->4 transition timeframe, have a macro, to "Allow Qt Containers", as well as code that does the autoconversion from Qt to STL, so developer code builds when the flag is on. Scott _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
