[Releasing] Qt 5 alpha 20120314: linux g++ x86_64 C++
lars.knoll at nokia.com
lars.knoll at nokia.com
Sun Mar 18 10:18:26 CET 2012
On 3/18/12 3:00 AM, "ext Girish Ramakrishnan" <girish at forwardbias.in>
>2012/3/17 Thiago Macieira <thiago.macieira at intel.com>:
>> On sábado, 17 de março de 2012 11.52.51, Girish Ramakrishnan wrote:
>>> I am unable to decide if this is a pass or a fail :)
>> Huh? You can't decide? :-)
>Well yeah, I can :) It's a failure by any measure.
>I am not entirely sure though what the motivation behind the alpha is.
>We are in a state where the whole build is in shambles. In my world,
>an alpha is one where all modules build and prefixed install should
>work. We can get no reasonable feedback if things are this broken.
>Suggesting people know the dependencies of modules and build the
>modules one by one by themselves sounds very cumbersome to me.
Yes, building Qt should be possible with reasonable effort. I think
there's two things we should be looking at tomorrow:
* Decide which modules are part of the alpha. The alpha is mostly there
for showing the new features and getting feedback on them. We can afford
to throw some non essential pars out.
* Make sure we have a reasonable way of building Qt on the reference
platforms. I don't mind if certains ways of building don't work as long as
there is *one* way to build it. Ideally that way is rather simply (e.g. a
top level build script).
>So, if alpha is a "state" of code (feature frozen, no api changes etc)
>rather than a "release", let's not make source packages. The code is
>simply in alpha state and let's make an announcement. Maybe create a
>tag to mark the date. (Personally, I like this idea. Let's get all
>this sorted out for a real beta release.).
I still think there's value in an alpha release if we can get a way to
build it. We need to fix build issues anyway and the sooner the better.
Let's see tomorrow. A lot of people are actually in Oslo next week. If we
focus on it, I very much believe we can get most things sorted in the next
couple of days.
>Otherwise, we need to move the alpha date and spend some more time
>fixing and testing all these build issues. We cannot "release" an
>alpha which has entire essential modules absent. I would feel bad to
>release a tar ball in it's current shape and waste an alpha tester's
>Releasing mailing list
>Releasing at qt-project.org
More information about the Releasing