[Development] Proposal: New branch model

[Jaroslaw Kobus]

________________________________________
From: Volker Hilsheimer
Sent: Wednesday, January 23, 2019 5:25 PM
To: Jaroslaw Kobus
Cc: Jedrzej Nowacki; development at qt-project.org
Subject: Re: [Development] Proposal: New branch model

On 23 Jan 2019, at 17:08, Jaroslaw Kobus <Jaroslaw.Kobus at qt.io<mailto:Jaroslaw.Kobus at qt.io>> wrote:

"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5"

No sure I understand the above correctly. Let's say in dev branch some source file got refactored completely, so that no single line match the old version anymore, e.g. Qt 5.9. Now you need to fix the old code, which is in 5.9 branch - how in this case you may try to push your fix to dev?

Jarek


That’s where the “with exception of branch specific changes” clause (which the ** points at) kicks in.

Is the fix needed in dev (or is the bug fixed by the refactoring)?

If yes, then fix it in dev, and then make a separate fix in the relevant LTS branches (perhaps starting with the cherry-pick’ed change). Or just accept that this bug won’t/can’t be fixed in the pre-refactoring codebase.

If no, then push the fix for the newest branch where it’s needed, from where it can be cherry picked further; don’t do anything in dev (including “don’t expect someone that knows nothing about your change to deal with the merge conflict”).


Volker


In this case there is additional step then. You would be forced now to check first both 5.9 and dev branches and detect if a fix would be "applyable" to the dev or not.

Besides, if you decide that your fix goes only to the 5.9 branch - in this case you follow the current model anyway, right? So, having two models isn't better than having just one I think.

Jarek