ent: tiistaina 28. maaliskuuta 2017 10.33
> To: Jani Heikkinen ; Lars Knoll ; Alex
> Blasche
> Cc: Qt development mailing list
> Subject: RE: [Development] Proposal to adjust release candidate process
>
> Releasing beta more frequently is a welcomed item, for sure.
>
> Ho
che
> Cc: Qt development mailing list
> Subject: Re: [Development] Proposal to adjust release candidate process
>
>
> > -Original Message-
> > From: Development [mailto:development-
> bounces+jani.heikkinen=qt.io@qt-
> > project.org] On Behalf Of Lars K
> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Lars Knoll
> Sent: tiistaina 28. maaliskuuta 2017 9.33
> To: Alex Blasche
> Cc: Qt development mailing list
> Subject: Re: [Development] Propo
> On 28 Mar 2017, at 07:04, Thiago Macieira wrote:
>
> On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote:
>>> Maybe every week is too aggressive, since few people will test every week
>>> and give feedback in time for the next release. We may find that every
>>> other week
> On 28 Mar 2017, at 08:09, Alex Blasche wrote:
>
>
>>> Sounds good, but please remember we'll need to keep at least the source
>>> tarballs for each and every beta and RC that we release.
>>
>> Yeah, that's OK
>
> This implies that the user can identify the exact tag or version (aka beta 5)
>> Sounds good, but please remember we'll need to keep at least the source
>> tarballs for each and every beta and RC that we release.
>
>Yeah, that's OK
This implies that the user can identify the exact tag or version (aka beta 5)
somewhere in the installer. Each bug report has to state this va
> On Mar 28, 2017, at 07:04, Thiago Macieira wrote:
>
> On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote:
>>> Maybe every week is too aggressive, since few people will test every week
>>> and give feedback in time for the next release. We may find that every
>>> other week
On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote:
> > Maybe every week is too aggressive, since few people will test every week
> > and give feedback in time for the next release. We may find that every
> > other week is better.
>
> Yes, the goal is to have new beta n about
>
> Sounds good, but please remember we'll need to keep at least the source
> tarballs for each and every beta and RC that we release.
>
Yeah, that's OK
> Maybe every week is too aggressive, since few people will test every week
> and give feedback in time for the next release. We may find that
On segunda-feira, 27 de março de 2017 02:40:08 PDT Jani Heikkinen wrote:
> 2. After first beta release we don't deliver any binary snapshots anymore
> but do release additional beta releases ~ once per week (with more
> lightweight process than current releases are done: no blog post from every
> b
lopment-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of
Simon Hausmann
Sent: perjantaina 23. joulukuuta 2016 19.02
To: Thiago Macieira ; development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Ahhh, I'm sorry, I
7 10:02 AM
To: Simon Hausmann; Thiago Macieira; development@qt-project.org;
releas...@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Hi,
Perhaps it is best to talk with marketing about the name of the “release done
immediately after branching to the .0
On 04/01/2017 16:25, Frederik Gladhorn wrote:
On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote:
Hi,
Perhaps it is best to talk with marketing about the name of the "release
done immediately after branching to the .0 release branch". Reading the
discussion, it seems that other than
ween FF and Alpha as well as between Alpha and
> Beta. But that is something we can discuss later.
>
> Yours,
>
> Tuukka
>
>
> From: Development
> [mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf
> Of Simon Ha
Since general churn while "stabilising" is a central part of the
discussion, let's take a look at the change, since my early November API
review push, in just the not-obviously-boring[*] changes to API-related
headers. ([*] If you can see any changes in the reviews that a dumb
script could be taugh
t-project.org]
On Behalf Of Tuukka Turunen
Sent: tiistai 3. tammikuuta 2017 10.02
To: Simon Hausmann ; Thiago Macieira
; development@qt-project.org;
releas...@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Hi,
Perhaps it is best to talk with marketing
ounces+simon.hausmann=qt...@qt-project.org>>
on behalf of Thiago Macieira
mailto:thiago.macie...@intel.com>>
Sent: Friday, December 23, 2016 4:42:12 PM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Proposal to adjust release candidate
lopment@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
escreveu:
> I find that the branch is relevant in this context, as it relates to the
> amount of patches going in. The amount of pat
Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
escreveu:
> I find that the branch is relevant in this context, as it relates to the
> amount of patches going in. The amount of patches going in is IMO related
> to the probably of introducing regressions. The process around
@intel.com
Sent: December 23, 2016 14:20
To: development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Em sexta-feira, 23 de dezembro de 2016, às 07:17:01 BRST, Tuukka Turunen
escreveu:
> > Call it beta 2 (or gamma 1) right after branch and one we
Em sexta-feira, 23 de dezembro de 2016, às 07:17:01 BRST, Tuukka Turunen
escreveu:
> > Call it beta 2 (or gamma 1) right after branch and one we've iterated and
> > we could have released, we call it release candidate. We release them
> > more often, with more iterations, so that we get more feedb
> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Robin Burchell
> Sent: perjantaina 23. joulukuuta 2016 3.40
> To: development@qt-project.org
> Subject: Re: [Development] Proposal to adjust release
> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: torstaina 22. joulukuuta 2016 22.09
> To: development@qt-project.org
> Subject: Re: [Development] Proposal to adj
My (slightly delayed) $0.02:
On releasing in general: I would agree that releases take too long,
often, but I am of the belief that a good part of this is a mess of our
own making. For instance, due to an end-user or project requiring a
specific version or purely out of fear that the next release
Em quinta-feira, 22 de dezembro de 2016, às 12:54:08 BRST, Tuukka Turunen
escreveu:
> > And besides, alpha and beta are traditional and well understood.
> > (Following that pattern though, I guess we ought to call the RC a
> > “gamma”, but that’s not traditional for some reason.)
>
>
>
> If we
Subject: Re: [Development] Proposal to adjust release candidate process
On 22 Dec 2016, at 08:09, Maurice Kalinowski
wrote:
Hence,
Technology Preview
Preview
Release Preview
Release Candidate
Release
Tech Preview is so far the term for a module which is released but we
reserve the right to
> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Shawn
> Rutledge
> Sent: torstaina 22. joulukuuta 2016 9.25
> To: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Developmen
> On 22 Dec 2016, at 08:09, Maurice Kalinowski wrote:
>
> Hence,
>
> Technology Preview
> Preview
> Release Preview
> Release Candidate
> Release
Tech Preview is so far the term for a module which is released but we reserve
the right to continue making API changes anyway, right? So changing
-project.org
Betreff: Re: [Development] Proposal to adjust release candidate process
I think many users see a beta as something you better not touch, but a release
candidates can be trusted much more. I know it's not intended that way but
people learned by experiences. [??]
Maybe "pre r
to show the final status?
From: Development on
behalf of Thiago Macieira
Sent: Wednesday, December 21, 2016 3:45:37 PM
To: development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Em ter?a-feira, 20 de dezembro de 2016, ?s 13:34:39 BRST, Tuuk
Em terça-feira, 20 de dezembro de 2016, às 13:34:39 BRST, Tuukka Turunen
escreveu:
> If desired, we could use some other name than "Release Candidate 1" for the
> release that begins the last phase of the release. It could be called "Beta
> 2" or "Technology preview", if so desired. Personally, I
Hi,
> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Sean Harmer
> Sent: Tuesday, 20 December 2016 16:14
> I wonder how much of the current pressure on releases is driven by the time-
> based release policy. We a
> -Original Message-
> From: sean.harmer On Behalf Of Sean Harmer
> Sent: tiistaina 20. joulukuuta 2016 17.14
> To: development@qt-project.org
> Cc: Tuukka Turunen ; releas...@qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
>
On Tuesday 20 December 2016 15:14:17 Sean Harmer wrote:
> Hi Tuukka,
>
> I agree with your proposal, however I think there is also another issue or
> two that we should address.
Except that instead of calling it RC1 why not call it another beta? The RC
should be something that *may* be suitable
Hi Tuukka,
I agree with your proposal, however I think there is also another issue or two
that we should address.
At present we have ~ 4 releases per year 2 minor versions and 2 further patch
releases. One issue is that it looks like 5.8.0 will soon render the very new
5.7.1 release redundant.
> On 20 Dec 2016, at 14:34, Tuukka Turunen wrote:
>
>
> Hi,
>
> I think we have three major problems with our current release process
> regarding the release candidate phase:
> 1. Process to make a RC that is as flawless as final causes
> inefficiency as we only get full test coverag
Hi,
I think we have three major problems with our current release process regarding
the release candidate phase:
1. Process to make a RC that is as flawless as final causes inefficiency
as we only get full test coverage with the RC itself
2. We get full attention for testing a bit
37 matches
Mail list logo
