Documenting the scope of Qt 5.0

Post by h***@nokia.com
Hi all,
We have started to document the scope of Qt 5.0 in terms of the platform
configurations and modules: http://developer.qt.nokia.com/wiki/Qt_5.0
The data is based on talking to the people working on different modules.
Obviously this is only a draft that will change, as Qt 5.0 hasn't been
frozen, open governance is not yet live, some modules might not make it to
the 5.0 release etc.

Why are you planning to support 32-bit Intel Compiler but not 64 bit? It would be
more reasonable to do vice versa.

--
Regards,
Konstantin

Thiago Macieira

2011-09-26 11:32:15 UTC

Post by Konstantin Tokarev
Why are you planning to support 32-bit Intel Compiler but not 64 bit? It
would be more reasonable to do vice versa.

Intel Compiler support is provided by Intel.

We started with 32-bit because that's the most important one (for MeeGo).
Given the availability of resources, 64-bit, Mac and Windows support will be
added.

I've been building 64-bit with ICC for a month now and it works flawlessly
(aside from a small compatibility fix in V8, where the comments already make it
clear that it's non-standard behaviour and differs from compiler to compiler --
it's nice that V8 relies on undefined behaviour...).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

Stephen Kelly

2011-09-26 11:08:28 UTC

included in the release. No compatibility promise

What is this about? There is no binary or source compatibility promise for
the QtTest module? Or do I misunderstand?

Post by h***@nokia.com
Qt DBus Needed because of dependencies. not cross-platform

What would it take for this to be considered cross-platform?

Thiago Macieira

2011-09-26 11:29:53 UTC

Post by Stephen Kelly

Post by h***@nokia.com
Qt Test Needed for conformance testing but not required to be
included in the release. No compatibility promise

What is this about? There is no binary or source compatibility promise for
the QtTest module? Or do I misunderstand?

No binary compatibility promise. Your tests should continue to compile, but
you need to recompile your tests if you upgrade Qt.

However, given the advantage of being able to run the same tests against
multiple versions, compatibility shouldn't be broken often. But don't submit
bugreports when that happens.

Post by Stephen Kelly

Post by h***@nokia.com
Qt DBus Needed because of dependencies. not cross-platform

What would it take for this to be considered cross-platform?

Willpower. D-Bus on Windows works fine for KDE and is being used by multiple
applications. Since Symbian is out of the picture, it's fine everywhere.

We just have to declare it so and start testing the build.

Olivier Goffart

2011-09-26 12:00:42 UTC

Post by Stephen Kelly

Post by h***@nokia.com
Qt Test Needed for conformance testing but not required to be
included in the release. No compatibility promise

What is this about? There is no binary or source compatibility promise
for the QtTest module? Or do I misunderstand?

No binary compatibility promise. Your tests should continue to compile, but
you need to recompile your tests if you upgrade Qt.

That is a bit annoying for binary compatibility tests....

(That is: running the old tests with the new Qt (and maintaining a list of
known to fail test due to intentional behaviour changes))

Well, one solution would be to be able to use the old QtTestLib with the newer
Qt, (if QTestLib would not use private Qt API)

Konstantin Tokarev

2011-09-26 11:12:22 UTC

What is "new low level C++ API" for QtWebKit? Will we be able to use WebKit 2
in pure C++ applications?

--
Regards,
Konstantin

l***@nokia.com

2011-09-26 12:10:55 UTC

Post by Konstantin Tokarev

What is "new low level C++ API" for QtWebKit? Will we be able to use WebKit 2
in pure C++ applications?

Nobody knows yet how it'll exactly look like. What we know is that we will
need the WebKit2 process separation for at least browsers, and that the
current API can not support it.

Cheers,
Lars

Thiago Macieira

2011-09-26 12:38:08 UTC

Post by l***@nokia.com

Post by Konstantin Tokarev
What is "new low level C++ API" for QtWebKit? Will we be able to use WebKit 2
in pure C++ applications?

Nobody knows yet how it'll exactly look like. What we know is that we will
need the WebKit2 process separation for at least browsers, and that the
current API can not support it.

Is that supposed to address the need for adding API to the JS world? For
example, providing extra API to access some functionality on my device (e.g.
"start coffee brewing"), which is not likely to be part of HTML 5 any time
soon.

Balagopalakrishnan, Anand

2011-09-26 12:20:31 UTC

I don't see any of the "embedded" platforms for Qt 5.0. There is mention of Linux, ARM7. Is this ARM7TDMI (which is almost ancient) or ARM-v7a (Cortex-A8/A9/...)? What's the specific EVM that's planned?

BeagleBoard and Panda were some of the reference platforms used in Qt4. Are they no longer supported?

Regards,
Anand

-----Original Message-----
From: qt5-feedback-bounces+anandb=***@qt.nokia.com [mailto:qt5-feedback-bounces+anandb=***@qt.nokia.com] On Behalf Of ***@nokia.com
Sent: Monday, September 26, 2011 4:28 PM
To: qt5-***@qt.nokia.com
Subject: [Qt5-feedback] Documenting the scope of Qt 5.0

Hi all,

We have started to document the scope of Qt 5.0 in terms of the platform
configurations and modules: http://developer.qt.nokia.com/wiki/Qt_5.0
The data is based on talking to the people working on different modules.

Obviously this is only a draft that will change, as Qt 5.0 hasn't been
frozen, open governance is not yet live, some modules might not make it to
the 5.0 release etc.

Best regards,
Henry

Thiago Macieira

2011-09-26 12:59:56 UTC

Post by Balagopalakrishnan, Anand
I don't see any of the "embedded" platforms for Qt 5.0. There is mention of
Linux, ARM7. Is this ARM7TDMI (which is almost ancient) or ARM-v7a
(Cortex-A8/A9/...)? What's the specific EVM that's planned?
BeagleBoard and Panda were some of the reference platforms used in Qt4. Are
they no longer supported?

Hi Anand

I think we need to split the "Qt project support" from what consulting
companies support, and we need to understand the difference between reference
platforms and supported platforms. For example, I'd remove the reference to
Ubuntu from the platform list, seeing as the support has nothing to do with
Ubuntu -- as long as it's Linux with the proper configuration, it should be
supported.

So I'd consolidate the list as:
Linux x86 32-bit, X11 & Wayland
Linux x86-64, X11 & Wayland
Linux ARMv7, X11 & Wayland
(maybe dropping X11 support for ARM)

The reference platforms are those that are mandated by the project and new
features must work (or at least gracefully fail) on all of them. I believe the
ARMv7 support with Wayland is the one targeted at embedded systems. In the
specific case of ARM, I think we need a good coverage of Cortex-A9s, to detect
multiprocessor issues, if any.

Supported platforms are, however, provided depending on the interest and
availability of people working on those platforms. That is valid for
architectures[1] as well as operating systems[2] or middleware stack[3]. Some
of those more interesting platforms will get commercial backing and/or lots of
interested people, so support should be almost a given for them too.

That said, access to hardware would be appreciated. Maybe TI could help out
with Panda Boards or even older devices for people interested in supporting
them.

[1] e.g. ARMv6, MIPS, PowerPC, UltraSparc, IA-64, SH-4, but also x86-64 ILP32
[2] e.g. AIX, Solaris, HP-UX, QNX, iOS
[3] that's where Android comes in

h***@nokia.com

2011-09-26 13:13:09 UTC

[...] For example, I'd remove the
reference to Ubuntu from the platform list, seeing as the support has
nothing to do with Ubuntu -- as long as it's Linux with the proper
configuration, it should be supported.
Linux x86 32-bit, X11 & Wayland
Linux x86-64, X11 & Wayland
Linux ARMv7, X11 & Wayland
(maybe dropping X11 support for ARM)

This list aims to be specific enough to describe what actually would run in the continuous integration system, hence it mentions Ubuntu. In the release documentation or product documentation, we should be more generic, "extrapolate", and include the other non-reference platforms that have been verified.

See related discussion from QtCS here:
http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition#4582cf86974b397c8f3a2ed2fd502f8c

Cheers,
Henry

Thiago Macieira

2011-09-26 13:28:52 UTC

Post by Thiago Macieira
Linux x86 32-bit, X11 & Wayland
Linux x86-64, X11 & Wayland
Linux ARMv7, X11 & Wayland
(maybe dropping X11 support for ARM)

I think that's doing it the other way around. The release documentation should
list exactly where it was tested, but the reference platforms should be
generic enough.

For example, if someone writes a feature that compiles on Ubuntu but fails to
compile on Fedora, it's still in need of fixing. Such errors would be usually
cases of depending on undefined or buggy behaviour in one of the libraries
installed or of the compiler, so they should thankfully be quite rare.

h***@nokia.com

2011-09-26 14:15:45 UTC

Post by h***@nokia.com
This list aims to be specific enough to describe what actually would
run in the continuous integration system, hence it mentions Ubuntu.
In the release documentation or product documentation, we should be
more generic, "extrapolate", and include the other non-reference
platforms that have been verified.

I think that's doing it the other way around. The release documentation
should list exactly where it was tested, but the reference platforms should
be generic enough.

Yes. The release documentation should list where it was tested -- but it can also document where it is reasonable to expect Qt to work (in other words it is OK to "extrapolate").

Post by Thiago Macieira
For example, if someone writes a feature that compiles on Ubuntu but fails
to compile on Fedora, it's still in need of fixing.

Yes, we would like it to be fixed.

Should a contribution be reverted if it turns out that it brings up a bug in Fedora that is hard to work around?

What are the distributions where we _require_ such bugs to be fixed (=reference configurations), as opposed to platform configurations where we would like Qt to work on? If we don't specify the reference configurations based on what runs in the CI system, then shouldn't we document them explicitly in some other way?

Best regards,
Henry

Thiago Macieira

2011-09-26 14:25:54 UTC

Post by h***@nokia.com
Yes. The release documentation should list where it was tested -- but it
can also document where it is reasonable to expect Qt to work (in other
words it is OK to "extrapolate").

Agreed.

Post by Thiago Macieira
For example, if someone writes a feature that compiles on Ubuntu but fails
to compile on Fedora, it's still in need of fixing.

Yes, we would like it to be fixed.
Should a contribution be reverted if it turns out that it brings up a bug in
Fedora that is hard to work around?

It depends. If it's a bug in the distribution, then we would usually point the
finger and say "it's your fault, please get it fixed". But if it turns out that
this particular issue is widespread and affects too many people, we should try
and work around it.

Post by h***@nokia.com
What are the distributions where we _require_ such bugs to be fixed
(=reference configurations), as opposed to platform configurations where we
would like Qt to work on? If we don't specify the reference configurations
based on what runs in the CI system, then shouldn't we document them
explicitly in some other way?

As a matter of practicality, knowing which configurations are running in the CI
system is useful. Of course it must compile and succeed in testing in those
configurations, or your code won't get in. For that reason alone, those are
platforms where the bugs must be fixed or worked around.

But not the only platforms. Let me ask the inverse of your question: should a
contribution be accepted if it turns out that it requires buggy or specific
behaviour only found in the installations present in the CI system? I'd say
the answer is no.

Think for example the work that Peter and Zeno did when they added support for
loading the system CA certificates. If they had proposed it with only the path
found on Debian and Ubuntu systems, it would not have been acceptable.

In some cases, we might find out that the installations in the CI system need
to be fixed instead.

C***@csiro.au

2011-09-27 00:03:17 UTC

Post by Thiago Macieira
Linux x86 32-bit, X11 & Wayland
Linux x86-64, X11 & Wayland
Linux ARMv7, X11 & Wayland
(maybe dropping X11 support for ARM)

I think that's doing it the other way around. The release documentation should
list exactly where it was tested, but the reference platforms should be
generic enough.
For example, if someone writes a feature that compiles on Ubuntu but fails to
compile on Fedora, it's still in need of fixing. Such errors would be usually
cases of depending on undefined or buggy behaviour in one of the libraries
installed or of the compiler, so they should thankfully be quite rare.

This discussion about what to make a reference platform vs documented platform seems to be specific to Linux (okay, maybe embedded too, but discussion seems to be mostly about linux at this stage). I put it to the list that this is precisely what the LSB is meant to address. Most of the work has already been done to make Qt build against LSB 4.0 (by Harald Fernengel and myself). Why not make LSB 4.0 the reference *and* documented platform for linux? Then the only question is whether or not a particular flavour of linux supports the LSB spec, and this is something that all the major linux distros generally try to do. Yes, there will be the odd need for a specific hack/fix to work around the occasional distribution-specific deficiency or bug, but I'm only aware of one such case in order to m
ake Qt build against LSB 4.0. Qt5 would seem to be the perfect time to make LSB 4.0 a tier 1 config/platform for Qt.

Currently, I maintain a smallish patch set for each Qt release to make it buildable with LSB (almost all the patches now are confined to webkit). I'd be more than happy to work with others if there was interest in making LSB 4.0 a tier 1 config/platform for Qt. Currently, I can only work on this as my current role allows, so some help would be welcome. Granted, there are some issues around OpenGL versions, but those are easily resolved by adding an additional constraint that sits on top of LSB 4.0 (and which looks to be getting addressed by upcoming LSB versions anyway). The only module I have not yet built against LSB 4.0 is DBus, since it isn't part of the LSB, but Thiago has already indicated in a previous response that providing the DBus headers to Qt should be enough since it will try
to load the QtDBus module dynamically at run-time and still work fine if it can't be loaded.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

Thiago Macieira

2011-09-27 08:34:13 UTC

Post by C***@csiro.au
This discussion about what to make a reference platform vs documented
platform seems to be specific to Linux (okay, maybe embedded too, but
discussion seems to be mostly about linux at this stage). I put it to the
list that this is precisely what the LSB is meant to address. Most of the
work has already been done to make Qt build against LSB 4.0 (by Harald
Fernengel and myself). Why not make LSB 4.0 the reference *and* documented
platform for linux? Then the only question is whether or not a particular
flavour of linux supports the LSB spec, and this is something that all the
major linux distros generally try to do. Yes, there will be the odd need
for a specific hack/fix to work around the occasional distribution-specific
deficiency or bug, but I'm only aware of one such case in order to make Qt
build against LSB 4.0. Qt5 would seem to be the perfect time to make LSB
4.0 a tier 1 config/platform for Qt.
Currently, I maintain a smallish patch set for each Qt release to make it
buildable with LSB (almost all the patches now are confined to webkit). I'd
be more than happy to work with others if there was interest in making LSB
4.0 a tier 1 config/platform for Qt. Currently, I can only work on this as
my current role allows, so some help would be welcome. Granted, there are
some issues around OpenGL versions, but those are easily resolved by adding
an additional constraint that sits on top of LSB 4.0 (and which looks to be
getting addressed by upcoming LSB versions anyway). The only module I have
not yet built against LSB 4.0 is DBus, since it isn't part of the LSB, but
Thiago has already indicated in a previous response that providing the DBus
headers to Qt should be enough since it will try to load the QtDBus module
dynamically at run-time and still work fine if it can't be loaded.

Hello

I think Qt should build with the LSB, yes. But making it our reference
platform will not exactly work, as the LSB 4.0 is now several years out of
date. I can't get the details as the website seems to still be down related to
Linux Foundation's infrastructure downtime.

The LSB isn't meant to innovate in the area of support. It's meant to
standardise best practice across the industry. For that reason, it's always
behind in terms of support and will usually lag one year behind the state of
the art or more. When developing for the future, we need to look at what the
state of the art of everything else will be, not what Red Hat Enterprise Linux
and SUSE LInux Enterprise Server shipped in 2008. (And by "look at" I don't
mean "always use")

Take for example Wayland: when will it be available in the LSB for us to build
against?

Anyway, what we can do is provide documentation on what we require by using
the LSB as the baseline: it's LSB 4.0 plus these libraries upgraded and these
other libraries present.

C***@csiro.au

2011-09-27 08:48:31 UTC

Agreed, it does lag. The LSB guys are aware of this and there have been discussions about changing that so that they are much closer to the current / leading distros.

Post by Thiago Macieira
The LSB isn't meant to innovate in the area of support. It's meant to
standardise best practice across the industry. For that reason, it's always
behind in terms of support and will usually lag one year behind the state of
the art or more. When developing for the future, we need to look at what the
state of the art of everything else will be, not what Red Hat Enterprise Linux
and SUSE LInux Enterprise Server shipped in 2008. (And by "look at" I don't
mean "always use")
Take for example Wayland: when will it be available in the LSB for us to build
against?
Anyway, what we can do is provide documentation on what we require by using
the LSB as the baseline: it's LSB 4.0 plus these libraries upgraded and these
other libraries present.

I'd very much support this approach. Making LSB 4.0 the base with a (hopefully small) list of libraries you need to update to something more recent would be a welcome change for people working on or supporting a wider range of linux distributions than simply Ubuntu. In many cases, LSB 4.0 + a few libs would probably be satisfied out of the box on recent distros, so for those who like to be more current, things should "just work" for them. For those who need to stay on older systems, at least the libs that need to be updated or provided as part of the application's packages would be clearly defined.

Another benefit of taking the LSB 4.0 + some libs approach is that it sends very clear messages to the LSB guys as to what things they should consider adding to the next version of the LSB spec itself. Currently, I get the feeling that there's not a whole lot of communication going between the Qt and LSB communities, which is funny considering Qt itself is part of the LSB!

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

h***@nokia.com

2011-09-28 12:20:00 UTC

I have some comments on the target platforms.
On all platforms, Open GL (ES) 2.0 is required.
linux-x86-32-gcc-x11 Ubuntu Linux 10.04 ×86 32 bit, X11
linux-x86-64-gcc-x11 Ubuntu Linux 10.04 ×86 64 bit, X11
linux-x86-32-gcc-wayland Linux Ubuntu 10.04 ×86 32-bit, Wayland
I think that Ubuntu 10.04 maybe too old already. The Mesa version shipped
on that Ubuntu can't do GLES2.0 AFAIK. Also I think there is no wayland
compositor available out-of-the-box. In other words, to actually test Qt5
with wayland and GLES2.0 on Ubuntu 10.04, you probably have to change the
environment to the point where it's no longer accurate to call it "Ubuntu
10.04".
We already plan to test with Ubuntu 11.10 in CI, so the question is whether
or not 10.04 should be kept as well.

Probably not. I updated the table for now along these lines.

Thiago, Craig: if we later agree to use something LSB based, let's then update this. I changed the headings of the table to indicate that we're specifying the CI system configuration, rather than the reference platform, that might indeed be a bit more abstract and general..

linux-arm7-gcc-wayland Linux, ARM7, Wayland gcc 4.5 ?
The platform must be specified more completely. Right now it specifies that
the kernel is Linux, CPU is ARMv7, "wayland" is used somehow and gcc 4.5
may be used. There's a lot of gaps to be filled in :) We should find some
existing platform which fits these specs, and specify that as the target
instead. If such a thing doesn't exist then I guess we shouldn't target it.

It'd be good to find a configuration in the CI for this. I documented that we need to specify this in more detail.

osx-10.7-64 Apple Mac OS X 10.7 “Lion” Cocoa 64 bit
osx-10.6-64 Apple Mac OS X 10.6 “Snow Leopard” Cocoa 64 bit
osx-10.6-32 Apple Mac OS X 10.6 “Snow Leopard” Cocoa 32 bit
Out of the listed platforms, Macs are the most expensive and least reliable
for CI purposes, so it would be really great if we could cut these down a bit.
At least testing 32-bit OSX 10.6 in CI is probably a waste (?) I would like to go
even further and do Qt 5.0 CI with OSX >= 10.7 only. Older OSX could still
have some release testing if it's perceived as valuable.

It would indeed be good to keep the list of reference configurations shorter. I moved 10.6 to the second table (platforms we would like to support).
(Well, I believe Tier 1 has been so far defined to be included in the CI, but anyways.)

Best regards,
Henry

C***@csiro.au

2011-09-29 01:50:33 UTC

Probably not. I updated the table for now along these lines.

I would strongly recommend you include Ubuntu LTS releases in your CI. These are specifically meant to be long-lived and so, by definition, won't go away quickly. Yes, plenty of people move to the latest and greatest versions, but I think talk of removing 10.04 from the CI is premature at this stage. Granted, it's been out for 2 years now, but my understanding is that it is still the most recent LTS release available. 10.04 is apparently supported on desktops until April 2013 (longer on servers - April 2015, but that's probably not feasible to support in the CI).

Post by h***@nokia.com
Thiago, Craig: if we later agree to use something LSB based, let's then update this. I changed the headings of the table to indicate that we're specifying the CI system configuration, rather than the reference platform, that might indeed be a bit more abstract and general..

It'd be good to find a configuration in the CI for this. I documented that we need to specify this in more detail.

Again, I think suggesting that OSX 10.6 be dropped from the CI for Qt5 is premature. Heck, 10.7 has only been out a few months and there's still plenty of reasons why people would be cautious about updating to it, especially in the Enterprise world. The Qt 4.7 branch does not formally support 10.7 (you get warnings to that effect when you compile with it). The Qt 4.8 branch does support OSX 10.7, but Qt 4.8 hasn't even been released yet. It would seem prudent to keep OSX 10.6 in the CI for a while, at least in the initial stages of Qt5 to ensure that there are no compatibility surprises. I'm well aware of the cost of having to support OSX builds (we have to do likewise for our own software), since you can't legally virtualise it like you can the other platforms. Maybe someone with friends at Apple can convince them to sponsor a build server or two for you? :-P

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

Rohan McGovern

2011-09-29 04:02:15 UTC

Post by C***@csiro.au
I would strongly recommend you include Ubuntu LTS releases in your CI. These are specifically meant to be long-lived and so, by definition, won't go away quickly. Yes, plenty of people move to the latest and greatest versions, but I think talk of removing 10.04 from the CI is premature at this stage. Granted, it's been out for 2 years now, but my understanding is that it is still the most recent LTS release available. 10.04 is apparently supported on desktops until April 2013 (longer on servers - April 2015, but that's probably not feasible to support in the CI).

I was under the impression that 11.10 was also to be an LTS release,
but it seems I was mistaken. In that case we should definitely keep
10.04 also, but those will be without Wayland.

Post by C***@csiro.au

osx-10.7-64 Apple Mac OS X 10.7 Lion Cocoa 64 bit
osx-10.6-64 Apple Mac OS X 10.6 Snow Leopard Cocoa 64 bit
osx-10.6-32 Apple Mac OS X 10.6 Snow Leopard Cocoa 32 bit
Out of the listed platforms, Macs are the most expensive and least reliable
for CI purposes, so it would be really great if we could cut these down a bit.
At least testing 32-bit OSX 10.6 in CI is probably a waste (?) I would like to go
even further and do Qt 5.0 CI with OSX >= 10.7 only. Older OSX could still
have some release testing if it's perceived as valuable.

It would be good if we could somehow get some more data/feedback on who
might be interested to deploy a Qt 5.0 app on OSX 10.6. Right now I
have argued against it mostly for selfish reasons and I honestly have
no idea who cares about it :)

--
Rohan (Nokia)

m***@nokia.com

2011-10-04 07:05:30 UTC

Post by Rohan McGovern
It would be good if we could somehow get some more data/feedback on who
might be interested to deploy a Qt 5.0 app on OSX 10.6. Right now I
have argued against it mostly for selfish reasons and I honestly have
no idea who cares about it :)

I would like to require 10.7 for developing (with) Qt 5. My impression is that most developers are running that version anyway and I would rather not have to maintain 10.6 support during the Qt 5.0 development.

10.6 support can be implemented later on if someone is interested in doing the work, but I'm hoping this won't be a big issue by the time we get to the Qt 5.0 release.

Morten

C***@csiro.au

2011-10-04 07:13:57 UTC

Post by m***@nokia.com

I would like to require 10.7 for developing (with) Qt 5. My impression is that most developers are running that version anyway and I would rather not have to maintain 10.6 support during the Qt 5.0 development.
10.6 support can be implemented later on if someone is interested in doing the work, but I'm hoping this won't be a big issue by the time we get to the Qt 5.0 release.

While clearly this would make life easier for some developers, it's just too premature to move on yet. Lion has only just been out a few months. As I understand it, Qt5 is supposed to be aiming for a date sometime next year. That would mean that you'd be dropping support for a Mac OS version that was the latest up to only about a year before you drop it! I don't know that there would be too many cases in Qt's history where it dropped a mainstream desktop version so quickly......

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

m***@nokia.com

2011-10-05 13:10:35 UTC

Post by C***@csiro.au

Post by m***@nokia.com

I would like to require 10.7 for developing (with) Qt 5. My impression is that most developers are running that version anyway and I would rather not have to maintain 10.6 support during the Qt 5.0 development.
10.6 support can be implemented later on if someone is interested in doing the work, but I'm hoping this won't be a big issue by the time we get to the Qt 5.0 release.

After reviewing feedback on and off list it seems I have to make a quick retreat here and support 10.6, also for pre-release Qt 5.

For those who are interested, supporting 10.6 involves implementing alliterative code paths where we use API introduced in 10.7 int the main code path. This is usually not much code, and I would say the majority of effort is testing and verifying that Qt still compiles and runs on 10.6.

I would like to draw the line at 10.6 though, 10.5 will not be supported.

Morten

Robin Burchell

2011-10-04 07:16:50 UTC

Hi,

Post by m***@nokia.com
I would like to require 10.7 for developing (with) Qt 5. My impression is that most developers are running that version anyway and I would rather not have to maintain 10.6 support during the Qt 5.0 development.

Can you do an overview (off the top of your head) of what work this
actually entails? Isn't 10.7 mostly going to be a a superset of 10.6
functionality?

BR,

Robin

Konstantin Tokarev

2011-10-04 07:28:42 UTC

Post by Robin Burchell
Hi,

Can you do an overview (off the top of your head) of what work this
actually entails? Isn't 10.7 mostly going to be a a superset of 10.6
functionality?

It is, just like 10.6 is a superset of 10.5.

--
Regards,
Konstantin

Konstantin Tokarev

2011-10-04 07:37:05 UTC

Post by m***@nokia.com

I would like to require 10.7 for developing (with) Qt 5. My impression is that most developers are running that version anyway and I would rather not have to maintain 10.6 support during the Qt 5.0 development.
10.6 support can be implemented later on if someone is interested in doing the work, but I'm hoping this won't be a big issue by the time we get to the Qt 5.0 release.

BTW, is 10.5 already dropped, or it's just not in Tier 1?

--
Regards,
Konstantin

Konstantin Tokarev

2011-09-29 08:06:42 UTC

Post by C***@csiro.au
I would strongly recommend you include Ubuntu LTS releases in your CI. These are specifically meant to be long-lived and so, by definition, won't go away quickly.

Why not CentOS 5 then?

--
Regards,
Konstantin

C***@csiro.au

2011-09-29 08:17:25 UTC