[Development] Behavior-changing bugfixes in patch-level releases

[Volker Hilsheimer]

> On 12 Jul 2023, at 09:52, EXT Mitch Curtis via Development <development at qt-project.org> wrote:
> 
> Hi Arno,
>> 
>> Hey everyone,
>> 
>> what is the policy for adding behavior-changing bugfixes to patch-level
>> releases? Is this something to expect?
>> At the moment we operate under the assumption that bumping the patch-
>> level of Qt is pretty much a no-brainer and can be done without having to do
>> much in the way of validation.
>> 
>> If behavior changes in patch-level releases are to be expected, we'll have to be
>> more careful with bumping Qt.
>> 
> 
> I'm sorry to hear that.
> 
> As the developer who approved the change, I've left my thoughts here:
> 
> https://bugreports.qt.io/browse/QTBUG-114166?focusedId=734562&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-734562
> 
> In summary, I believe the official branch policy was followed here.

Without going into the details of this particular change:

The branch policy lives on http://quips-qt-io.herokuapp.com/quip-0016-branch-policy.html and deliberately leaves room for interpretation and case-by-case decision making. From a certain point of view, any bug fix can be seen as a behavior change, and side effects are not unusual, and not always expected or wanted. If a patch comes with a ChangeLog entry, then bringing it back into an “LTS Strict” (or even “Very Strict”) branch should not be done lightly. But in general, we do want to be able to make such fixes also in older branches.

We do generate release notes for patch release, i.e. https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.5.1/release-note.md where this particular change is included in the “Important Changes” section: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.5.1/release-note.md#qtdeclarative

The intention of those notes is to make it easier for people upgrading to evaluate the impact, and to decide whether some extra testing needs to be done before rolling the new version out to everyone.

But maybe this is not the most effective way to communicate changes like this. Are these notes easy enough to find? Is a single “Important Changes” section sufficient, or do we need more differentiation? Some important changes are marked as such because they fix a bad bug, others might be marked as important because they might require adaptation in existing code that relies on previous behavior. They are all marked as "Important Behavior Change” in the commit log, and usually with a module or even type name (in this case, "[ChangeLog][QtQuick][ListView][Important Behavior Change]”). Our commit template suggests “[ChangeLog][module][class/topic]”.

Perhaps the release-notes generation script could group things a bit better, at least by module rather than by repository, and also including the class/topic.

Ideas on how we can make this better are very welcome.

Volker