On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: > On 2017-03-14 13:33, André Pönitz wrote: > > In general, I am not overly sold on ABI compatibility promises. I personally > > could live without and find SC of more practical value. The most important > > "feature" of ABI compatibility guarantee for me is that it limits people > > from > > doing overly excessive source-incompatible changes. > > Distros are likely to care; a Qt BC break requires a mass rebuild of > everything that uses Qt (which translates into lots of users needing to > update lots of packages when Qt changes).
I am three steps away from understanding what you are saying: I don't get why a library (Qt or anything else) BC break would cause a distro to update packages outside their usual upgrade cycle (when most, or rather all, of the packages will be recompiled anyway), nor, in case the distro did it nevertheless, do I understand why a user would need to upgrade packages in that case, nor, in case the distro *and* the user consciously decided to upgrade, why that would be a problem. > Distros may refuse to update Qt within a distro release as a result, which > means > users are stuck with older Qt for longer. Yes, and, so what? We are not talking about security problems. What is wrong with running a half-year, or worst case maybe even a two year old version of some library as base for the bulk of the applications? > All that more or less already applies to the standard library however > (probably > most distros don't accept a standard library BC break without a mass rebuild > anyway), so Qt insulating against BC breaks in the standard library is maybe > less necessary. That was the starting point here. Not Qt breaking BC by itself, but allowing C++ BC breakages to affect otherwise "pure Qt" applications. Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
