[Development] [Releasing] Qt 5.0 alpha released

Turunen Tuukka Tuukka.Turunen at digia.com
Thu Apr 5 17:27:52 CEST 2012


I also prefer having a publicly accesible branch in which the release is stabilized in for 5.0 beta and final.

--

Tuukka



Girish Ramakrishnan kirjoitti 5.4.2012 17:55:

Hi,

On Thu, Apr 5, 2012 at 7:50 AM, <marius.storm-olsen at nokia.com<mailto:marius.storm-olsen at nokia.com>> wrote:
> On 04/05/2012 09:38 AM, ext Oswald Buddenhagen wrote:
>> On Thu, Apr 05, 2012 at 10:54:56AM -0300, ext Thiago Macieira wrote:
>>> On quinta-feira, 5 de abril de 2012 13.49.40, marius.storm-olsen at nokia.com<mailto:marius.storm-olsen at nokia.com>
>>> wrote:
>>>> Those were local in Simo's machine due to some cherry-picking of not yet
>>>> landed changed. I wanted to tag with reviewed an landed changes though
>>>
>>> Please upload the exact SHA-1 from Simo's machine because those are in the
>>> released package now.
>>>
>>> I recommend the procedure:
>>>
>>> per-module:
>>> 1) git tag -a the *exact* SHA-1 that are found on Simo's machine
>>>     if the module does not follow Qt's versioning, tag it as "qt-v5.0.0-alpha1"
>>>     retroactively setting the date too with GIT_COMMITTER_DATE
>>> 2) wait for the fixes to land
>>> 3) git merge -s ours v5.0.0-alpha1
>>> 4) push the merge, approve it, stage it
>>>
>> or just admit the screwup, and silently upload a tar-ball with the
>> corrected sha1s, for the sake of not uglifying the git history.
>> and just for good measure, let simo repeat "i will not bypass CI again"
>> about a thousand times.
>
> In the end it was Lars and my call, and Simo did as we said. We had to
> get the alpha out, and landing the patches in time was proving too
> difficult, even though the patches in question had been tested
> successfully on the T1 platforms.
>
> So I think the discussion should be more angled towards, releasing alpha
> from master branch proved too hard, and should we thus use a branch for
> the beta release? Or is this an inherit property of an alpha release,
> and beta will prove more stable?
>
> IMO, we should use a temporary CI tested branch for the release. CI
> failures do to unrelated stagings eat up valuable cycles.
>
> Lars and I also discussed putting a temporary hold on staging rights for
> anyone except maintainers during the release cycle. Opinions on that
> approach?
>

I would prefer not. Creating branches for the beta, regardless of
qt5's stableness, is the right thing to do. AFAICT, a very minor
percentage of the "staging" population was actually involved in
release testing. So, this will affect all their work for no real
benefit (since they are going to stage it at some point after the beta
anyway).

Girish
_______________________________________________
Development mailing list
marius.storm-olsen at nokia.com<mailto:marius.storm-olsen at nokia.com>
http://lists.qt-project.org/mailman/listinfo/development


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120405/745e5b99/attachment.html>


More information about the Development mailing list