On Fri, May 31, 2019 at 01:24:13PM +0000, 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
