Hi,
It is time to start freezing Qt 5.12 schedule. We have the same "limitation" as
earlier; we should get the release out well before Christmas time. And it seems
we can't cut the time needed from FF to final release that much. It seems we
aren't necessarily needing those 17 weeks as before bu
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 because I don't see that
> much need
> -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
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.
Unle
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 m
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 fixed in
> snapshot-140
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
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
o: Simon Hausmann
> Cc: Qt development mailing list
> Subject: 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 deliver
gt; > -Original Message-
> > From: Development > project.org> On Behalf Of Lars Knoll
> > Sent: maanantai 16. huhtikuuta 2018 10.03
> > To: Simon Hausmann
> > Cc: Qt development mailing list
> > Subject: Re: [Development] Qt 5.12 schedule propo
> -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
> -Original Message-
> From: Development project.org> On Behalf Of Frederik Gladhorn
> Sent: maanantai 16. huhtikuuta 2018 15.11
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release
> process change
>
> -Original Message-
> From: Alex Blasche
> Sent: maanantai 16. huhtikuuta 2018 16.47
> To: Jani Heikkinen
> Cc: Qt development mailing list
> Subject: 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
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,
> -Original Message-
> From: Edward Welbourne
> Sent: tiistai 17. huhtikuuta 2018 12.09
> To: Jani Heikkinen ; Alex Blasche
>
> Cc: Qt development mailing list
> Subject: 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. aft
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). The
18 matches
Mail list logo
