[Development] Qt 6.1 Feature Freeze is in effect now

[Jani Heikkinen]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Joerg Bornemann
> Sent: perjantai 5. helmikuuta 2021 9.57
> To: Volker Hilsheimer <volker.hilsheimer at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] Qt 6.1 Feature Freeze is in effect now
> 
> On 2/4/21 12:20 PM, Volker Hilsheimer wrote:
> 
> > 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?
> 
> Right, I was missing that you want to do the submodule update rounds for
> the 6.x branch instead of dev. I suppose that would work. To summarize, the
> process would be:
> 
> - branch off 6.x in all repos from whatever is currently is dev
> - do submodule update rounds for 6.x
> - needed fixes for submodule updates go into 6.x with Pick-to: dev
> 
> I like the simplicity. No bot fiddling and no "imminent not-yet-created
> branch" concept.
> 

Well, that might easy up things a bit. But I don't like the idea where we would do branching from a state where dependencies might be broken; this isn't just updating submodules in qt(5).git but also updating dependencies in modules as well. I think it is better to fix all issues at first in one branch and do the branching after that; that way we should be able to continue working normally immediately after branching in both branches instead of fixing 2 branches at same time...

But if all others thinks this is better way to do branching I can live with it as well ;D 

@Daniel Smith @Paul Wicking I think this wouldn't be so big change in our branching scripts, right?

br,
Jani