> On 10 Dec 2020, at 09:48, Lars Knoll <[email protected]> wrote: > >> On 9 Dec 2020, at 18:49, Thiago Macieira <[email protected]> wrote: >> >> On Wednesday, 9 December 2020 02:00:29 PST Benjamin TERRIER wrote: >>> Back to the topic, wouldn't it be acceptable to break BC before 6.2 release? >>> I mean Qt 6 isn't really complete until 6.2, so if a break is required it >>> kind of makes sense to make it happen before everyone has made the switch >>> from Qt 5 to Qt 6. >> >> That would effectively mean 6.0 and 6.1 are duds and should not be used. We >> should have called them 5.98 and 5.99 then. >> >> No, we either break BC before May 2021, before adoption really starts, or we >> wait until 2025. Anything in-between is not acceptable. > > I agree with that. If we have good enough reasons, we can consider this for > 6.1, but I would not want to do it after that. > > But we can of course consider shortening our time between major releases. As > Volker mentioned, we were doing major versions more often in the past, and > 3-4 years instead of 7-8 is something we should really consider. > > Cheers, > Lars
Hey, Lars and I reviewed the issues that are linked to https://bugreports.qt.io/browse/QTBUG-89157 and we believe that none of those issues provide a strong enough reason for breaking binary compatibility in Qt 6.1: * QTBUG-89090: we have lived with those issues through Qt 5 * QTBUG-89423: breaking SC by marking QStandardItemModel::data (and other overrides where a multiData reimplementation exists) as final might be an option; that doesn’t break BC. Otherwise, documenting the issue in affected classes. * QTBUG-89428: not a new problem * QTBUG-89439: not a new problem; can be solved through an API that maps coordinate systems * QTBUG-89199: so far just a theoretical problem * QTBUG-87465: seems to be solvable by adding setters to the item-widget classes * QTBUG-89205: security relevant, but proposed “Take 2” solution seems adequate * QTBUG-90327: API convenience; it should be possible to solve this with documentation There’s no question that it would be nice if we could address all these issues. But as long as they are all just “nice to have’s”, it doesn’t seem justified to break our established BC promise with Qt 6.1. However, the discussion is still open, and if you disagree with our conclusion, please speak up soon, and ideally prepare a patch with a proposal that addresses the problem. Feature freeze is in a few days, and we’ll start the header review soon after that, by which time we need to close this discussion. Volker _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
