Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>> ... I do like to emphasize though that the dates for first beta and >>> first RC are important (and FF is alpha) because they define times >>> when certain level of changes are no longer permitted (e.g. after >>> first beta no API changes).

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

On 17.04.2018 12:08, Edward Welbourne wrote: Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) ... I do like to emphasize though that the dates for first beta and first RC are important (and FF is alpha) because they define times when certain level of changes are no longer permitted (e.g.

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

> -Original Message- > From: Edward Welbourne > Sent: tiistai 17. huhtikuuta 2018 12.09 > To: Jani Heikkinen <jani.heikki...@qt.io>; Alex Blasche > <alexander.blas...@qt.io> > Cc: Qt development mailing list <development@qt-project.org> > Subj

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>... I do like to emphasize though that the dates for first beta and >>first RC are important (and FF is alpha) because they define times >>when certain level of changes are no longer permitted (e.g. after >>first beta no API changes). Therefore,

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

> -Original Message- > From: Jani Heikkinen > I have to disagree a bit: Alpha and beta phases are important and schedule > for FF > (and Alpha) as well. But for beta and RC we really don't need it: After API > review > is done we will enter in beta phase (and at this same time beta1 is

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

ntinue labeling those as earlier. > > > > br, > > Jani > > > > > -Original Message----- > > > From: Development <development-bounces+jani.heikkinen=qt.io@qt- > > > project.org> On Behalf Of Lars Knoll > > > Sent: maanantai 16. huhtikuuta

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

> -Original Message- > From: Development [mailto:development- > Keeping release tags is OK for me. Motivation behind my proposal was to stop > planning other release dates than FF & final target. Currently we are trying > to > estimate also alpha, beta and RC release dates and it seems to

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

l Message- > > From: Development <development-bounces+jani.heikkinen=qt.io@qt- > > project.org> On Behalf Of Lars Knoll > > Sent: maanantai 16. huhtikuuta 2018 10.03 > > To: Simon Hausmann <simon.hausm...@qt.io> > > Cc: Qt development mailing list <deve

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

nantai 16. huhtikuuta 2018 10.03 > To: Simon Hausmann <simon.hausm...@qt.io> > Cc: Qt development mailing list <development@qt-project.org> > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release > process change > > Hi, > > From a re

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Tuukka Turunen (16 April 2018 08:59) > I very much like continuous flow of snapshots. I don't think anyone is challenging that part of the plan. The only objection to the plan has been to the change in naming. > Sometimes we have a tendency to fall into a "let's wait and get still > this one fix

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi, From a releasing perspective I agree that the set we should update our packages often. We should also stop delivering source only alpha packages, and have binaries from the get go. But from a user perspective, I agree that it's good and important to put a name to those releases so people

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

On 16 April 2018 at 09:43, Simon Hausmann wrote: > Hi, > > Same here. At first this seemed like a good idea, but it becomes awkward when > you look at it from the dev workflow point of view: After fixing a bug, what > is the fix version? Reported in snapshot-24062918 and

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi, I very much like continuous flow of snapshots. Sometimes we have a tendency to fall into a "let's wait and get still this one fix in" mode, which is very inefficient. It is beneficial when making .x patch releases and the fix is for a regression. But in other situations, it is typically

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Hi, Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA.

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

> -Original Message- > On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > > And at this same time I want to propose that we stop delivering alpha > > or beta releases and just do snapshots instead. Publishing regular > > snapshots should be done until we are ready for RC. That