[Development] Qt 6.1 Feature Freeze is in effect now

[Volker Hilsheimer]

> On 3 Feb 2021, at 20:14, Joerg Bornemann <Joerg.Bornemann at qt.io> wrote:
>> But why not get rid of the gap in the first place, ie instead of having a gap between
>>> - final dependency update sha1s are fixed, full update round started
>>> - 6.1 branch is created
>> What stops us from simply creating the branch in the submodules, without caring about submodule updates? Does it matter that the fork-point itself provides a consistent set? I see how that makes some sense for the qt5.git repo, but not for the submodules.
> 
> Maybe I'm missing something, but AFAICT the problem is that the 6.1 branch's sha1 is not known until the dependency update round was successful. It could take several attempts until the dependency update goes through.
> 
> In your scenario, what are we going to do if a branch's sha1 needs to be updated due to a failed dependency update and there are already cherry-picks? I suppose we could rebase. Who resolves the conflicts then?


The 6.1 branch’s sha1 is whatever the sha1 in dev was when the branch was created. Things start to diverge from there, but at branching sha1, the new branch’s consistent set is whatever .qtmodules and dependencies.yaml states at that time. Does it matter whether .gitmodules points to the HEAD of that new branch? I suppose not, we are not releasing yet. If we release, we’d basically release dev’s last consistent set.

Then we cherry-pick changes into the new branch, and do the usual submodule process for that new branch. Eventually, we will have a consistent set again for the branch.

Some times, cherry-picks will break dependencies, and then we don’t have a consistent set. That’s the same situation, isn’t it?


Volker