> Am 26.05.2026 um 17:04 schrieb Marc Mutz via Development > <[email protected]>: > > > Refactoring, even huge ones, are completely safe and never change behaviour. > If they do, they're not refactorings, but something else.
With that definition for "Refactoring", refactorings do not exist, because you cannot guarantee this (at least not for more than trivial changes). For me that is fine then - there are no refactorings, so nothing to cherry-pick to stable branches... If it was possible to guarantee, bug fixes would always only change the behavior that they want to change, and unintended regressions would not exist. Reality shows different. > As for bug-fixes: they ought to be clearly communicated to users via > [ChangeLog], so users know what will come with the next update instead of > showing up as regressions in their projects. That leaves the unintended behavior changes of a bug fix which still show up as regressions. >>> - bugfixes should always be picked back >> ..and this depends on the nature and severity of the bug. > > Does it, now? Which customer wants to sit on a version of Qt with a known, > unfixed bug? Just because it hasn't hit them, yet, doesn't mean it won't hit > them in the future, or, worse, hit a customer of theirs. Yes it does depend. A bug that has been known for 5 years with a JIRA entry and existing workarounds is a known risk. A bugfix for that issue in a "stable" branch is an unknown risk. An unintended regression could be much worse, affects code that worked and was tested before, might not have workarounds etc. > what is more important? Regression-free stable branches, or TTM for security > fixes? Faster TTM for security fixes doesn't matter if app developers cannot upgrade Qt (or if the upgrade takes longer) because the upgrade breaks their applications. If stability is sacrificed for faster TTM for security fixes in the Qt code base that doesn't necessarily result in faster TTM of the security fixes in the actual applications if the update of Qt is made harder because of breakages / behavior changes, intended or not. Aside from the question how much faster security fixes actually could be done in general (how much effort is backporting security fixes on average now? You own statement "your typical security fix (which tend to be one-liners more often than not)" seems to indicate that for most the effort is not high.) and the question of the risk of introducing new security issues in "stable" branches because of a "backport everything except features" policy. ++ Eike — Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany [email protected] https://www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
