[Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

Tuukka Turunen tuukka.turunen at qt.io
Tue Apr 11 15:48:32 CEST 2017



> On 11/04/2017, 16.09, "Stottlemyer, Brett (B.S.)" <bstottle at ford.com> wrote:
>
> > On 4/11/17, 7:36 AM, "Development on behalf of Tuukka Turunen" <tuukka.turunen at qt.io> wrote:
> > every fix that would have been part of 5.8.1 and more – a lot more. 
>    
>    The reason for pushing to the 5.8 branch is because it *is* stable.  And since it has "... a lot more", the 5.9 branch is not stable.  

I was actually not referring to features, but the fact that quite a lot of bug fixes have been pushed to 5.9 and these are not present in 5.8 branch.

> Whether The Qt Company will generate any packaged versions on the 5.8 branch after 
> the 5.8.0 release is really not the point, is it?
>    For those that are building from source and who have requirements for stability vs. new features, doesn't there need to be a stable HEAD to push to?  If the 5.8 branch is closed, those developers will be forced to move
>  to 5.9 beta, or be required to find, cherry-pick and validate commits onto 5.8 themselves, right?  Leaving the branch open, with CI runs on changes, seems like the only way to keep a known stable HEAD available until
>  the known stable HEAD is on the 5.9 branch.
    
The problem with pushing some fixes to 5.8 is that we need to do merges up (which need effort from people, machine cycles and calendar time). This is the penalty we take when there are patch releases coming from the stable branch. It is a major impact to the next release. 

Now that there are no patch releases planned, the benefit from pushing to 5.8 then merging to 5.9 does not exist. That is the key point – we need to create a stable base for users, catch up with lost time due to 5.8 delay, and to be able to implement a major change in CI so that we can make patch releases easier in the future.

So this is not about changing the approach in general – just a temporary action to be able to reach the abovementioned goals. 

Yours,

	Tuukka
    



More information about the Development mailing list