On Fri, Nov 18, 2016 at 08:37:26PM +0100, Marc Mutz wrote: > There's no reason for Qt to extend its BC guarantees to other libraries. STL, > GSL, Boost, std::exception, you name it. They are outside of Qt's realm and > therefore do not fall under the Qt BC rules. As with every other C++ library: > if a user wants BC, it's his job to pin libs without BC guarantees to a fixed > version. Not Qts.
If Qt *requires* a dependency that does not care about BC and leaks it into its interface, this effectively voids the value of Qt's current BC promise for the user, as, as you correctly stated, the burden of taking care of dependencies is now shifted to the sholders of a user caring for BC. Now we can discuss how much of a total loss of value of Qt that would be. My personal guess on a first approximation is "zero, because nobody is really affected". Typical users of Qt are: - people using Qt in a restricted environment that ship their application themselves, bundled with everything they use (read "Windows", or "certified environment", or "devices") They are not affected by BC breakages. If they need to update stuff they go from one blob to another blob, the only difference Qt BC in that scenario might be is the size of the delta blob. - people using Qt in applications distributed by packaging systems (read "Linux distributions"). They are not affected by BC breakages. - people providing packaging systems. They *are* affected. But since they already take care of a lot of other dependencies not caring for BC, Qt being on one side of the fence or the other does not make a fundamental difference. So: If you want to argue that using GSL, and std::exception would be beneficial for Qt, you might want to start with making a point about the value of the current BC promise. Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
