On Mon, Jun 30, 2014 at 08:58:58AM -0700, Thiago Macieira wrote:
Em seg 30 jun 2014, às 11:10:28, Jędrzej Nowacki escreveu:
What about creating an intermodule api, which would stay private from a
user point of view. We can agree on some rules, like for example not
removing symbols between
On Friday, June 27, 2014 09:34:19 Thiago Macieira wrote:
Em sex 27 jun 2014, às 10:57:14, Stephen Kelly escreveu:
I guess this is a subject for when and if the situation happens again.
Make that suggestion next time too.
The enginio situation happened because it was not actually
On Friday, June 27, 2014 12:37:21 Jocelyn Turcotte wrote:
We use private API, so:
- We need to only distribute QtWebEngine together with Qt, you can't
download QtWebEngine 1.0 that would work with both QtCore 5.4 and 5.5
- We have to bump our minor/patch version for each new minor/patch
On Friday, June 27, 2014 12:37:21 Jocelyn Turcotte wrote:
We'll always have a 1-to-1 mapping of QtWebEngine and Qt versions and
we'll always distribute/test them together. If we release QtWebEngine
1.u.v with Qt 5.x.y, then QtWebEngine 1.u+1.v will also depend on Qt 5.x.y.
This also looks like
On Friday, June 27, 2014 13:10:17 Thiago Macieira wrote:
Em sex 27 jun 2014, às 21:28:41, André Pönitz escreveu:
This pretty much sounds like If a module uses private API it should
follow Qt Core numbering, if it doesn't it's free to pick anything.
Sounds like a good compromise to me.
Not
On Friday, June 27, 2014 22:57:09 Giuseppe D'Angelo wrote:
On 27 June 2014 22:10, Thiago Macieira thiago.macie...@intel.com wrote:
Sounds like a good compromise to me.
If a module wants to release out-of-schedule, it will need to use an extra
version number, like 5.4.0.1.
The problem
On 30 June 2014 09:39, Stephen Kelly stephen.ke...@kdab.com wrote:
Having a huge difference between 5.4.0 and 5.4.0.1 doesn't seem wise to me.
That was just for the sake of the argument. If one decides to release
a new major version of the module today, what should its version
number be? I
On Friday, June 27, 2014 14:50:39 you wrote:
Hi,
It seems that Jocelyn answered most of the questions, but I put my answers
anyway :-)
On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote:
(...)
Conclusion 1) Even if a Qt module has a disparate version scheme, bumping
its
On 30 June 2014 09:50, Stephen Kelly stephen.ke...@kdab.com wrote:
Does 5.4.0 qualify?
How much testing does a 'new major version' need?
But according to that scheme that should the version number used when
linking against QtCore 5.4.0, shouldn't it?
--
Giuseppe D'Angelo
On 2014-06-30, Olivier Goffart oliv...@woboq.com wrote:
Totally off topic: I think using private header should be tried to be
avoided.
In the past, we used private header inside Qt because Qt was not split that
much. But one of the goal of modularisation was to allow independent release
On Monday, June 30, 2014 10:15:47 Giuseppe D'Angelo wrote:
On 30 June 2014 09:50, Stephen Kelly stephen.ke...@kdab.com wrote:
Does 5.4.0 qualify?
How much testing does a 'new major version' need?
But according to that scheme that should the version number used when
linking against
On 6/30/14, 10:06 AM, Olivier Goffart oliv...@woboq.com wrote:
I think there should be some kind of long term goal to avoid using
private
headers.
I totally agree with you on that. Private headers are private for a reason.
If API from a private header is needed outside the project itself,
On Monday, June 30, 2014 08:34:19 Albisser Zeno wrote:
This also implies if we just as an example cherry-pick a critical security
fix from chromium to Qt WebEngine, we would have to bump the version
number of the whole of Qt.
And therefore build and release new packages for everything. - And
On Sunday 29 of June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer wrote:
That's of course only the binary installer ... I can't judge whether e.g.
distributions would appreciate separate releases of QtWebEngine.
No if it uses private headers.
I currently need to rebuild on all
On 2014-06-30, Olivier Goffart oliv...@woboq.com wrote:
We need also to identify private APIs that could be polished and made public.
The first step here is, from your friendly packagers POV, the QPA
API's.
One thing is that we need to be very careful with combining the
components released by
On Monday 30 of June 2014 10:06:12 Olivier Goffart wrote:
On Sunday 29 June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer wrote:
No if it uses private headers.
I currently need to rebuild on all arches gammaray, fcitx-qt and pyqt5
each
time I upload a new point release for this
On Monday 30 of June 2014 09:48:05 Stephen Kelly wrote:
On Friday, June 27, 2014 14:50:39 you wrote:
Hi,
It seems that Jocelyn answered most of the questions, but I put my
answers
anyway :-)
On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote:
(...)
On Monday 30 June 2014 10:50:31 Jędrzej Nowacki wrote:
On Sunday 29 of June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer
wrote:
That's of course only the binary installer ... I can't judge whether
e.g.
distributions would appreciate separate releases of QtWebEngine.
No if it
Em seg 30 jun 2014, às 10:28:28, Stephen Kelly escreveu:
Qt minor releases are 6 months apart.
How realistic is it to conceive, plan, implement and test a 'new major
release' of an entire module in that timespan?
It might have been in the works for a year and is now ready to be released.
Em seg 30 jun 2014, às 09:36:39, Stephen Kelly escreveu:
If a module wants to release out-of-schedule, it will need to use an extra
version number, like 5.4.0.1.
And 5.4.1.1 and 5.4.2.1 etc.
Why?
Let's take an example applying right now: suppose module X is using the Qt
private API. As
Em seg 30 jun 2014, às 11:10:28, Jędrzej Nowacki escreveu:
What about creating an intermodule api, which would stay private from a
user point of view. We can agree on some rules, like for example not
removing symbols between patch releases, having some test coverage?
We can also call it
On Monday, June 30, 2014 08:56:31 Thiago Macieira wrote:
Em seg 30 jun 2014, às 09:36:39, Stephen Kelly escreveu:
If a module wants to release out-of-schedule, it will need to use an
extra
version number, like 5.4.0.1.
And 5.4.1.1 and 5.4.2.1 etc.
Why?
Let's take an example
Em seg 30 jun 2014, às 18:13:16, Stephen Kelly escreveu:
On Monday, June 30, 2014 08:52:45 Thiago Macieira wrote:
Em seg 30 jun 2014, às 10:28:28, Stephen Kelly escreveu:
Qt minor releases are 6 months apart.
How realistic is it to conceive, plan, implement and test a 'new major
On Friday 27 June 2014 11:28:14 Koehne Kai wrote:
[snip]
My 2 cents from the packaging/installer side: Any artifact that is heavily
bound to a specific Qt build / release, but isn't part of the Qt package
itself, is making things complicated.
As distro packager, yes, it's making things
On Thursday, June 26, 2014 08:38:01 Thiago Macieira wrote:
Em qui 26 jun 2014, às 09:52:20, Stephen Kelly escreveu:
Therefore
the
major version must stay the same until Qt 6.
Why is it not acceptable?
Because Lars did not accept it.
Well, the solution
Hi,
It seems that Jocelyn answered most of the questions, but I put my answers
anyway :-)
On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote:
(...)
Conclusion 1) Even if a Qt module has a disparate version scheme, bumping
its major version and changing its SONAME are not acceptable.
Em sex 27 jun 2014, às 10:57:14, Stephen Kelly escreveu:
I guess this is a subject for when and if the situation happens again.
Make that suggestion next time too.
The enginio situation happened because it was not actually discussed.
Because it was allowed under the previous guidelines.
On Fri, Jun 27, 2014 at 11:28:14AM +, Koehne Kai wrote:
-Original Message- From:
development-bounces+kai.koehne=digia@qt-project.org [...] We'll
always have a 1-to-1 mapping of QtWebEngine and Qt versions and we'll
always distribute/test them together. If we release
Em sex 27 jun 2014, às 21:28:41, André Pönitz escreveu:
This pretty much sounds like If a module uses private API it should
follow Qt Core numbering, if it doesn't it's free to pick anything.
Sounds like a good compromise to me.
If a module wants to release out-of-schedule, it will need to use
On 27 June 2014 22:10, Thiago Macieira thiago.macie...@intel.com wrote:
Sounds like a good compromise to me.
If a module wants to release out-of-schedule, it will need to use an extra
version number, like 5.4.0.1.
The problem with such scheme is that it doesn't make it obvious that
there
On Wednesday, June 25, 2014 09:32:15 Thiago Macieira wrote:
Em qua 25 jun 2014, às 17:57:35, Stephen Kelly escreveu:
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
This is of course the same situation that could arise
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Proposal 1) All Qt modules must use the major version '5' for consistency.
There's a difference between this is a Qt 5 library and this is a Qt
library with version 5. We agreed to hardcode QtCore's version number in
every
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
New modules should be allowed to choose their numbering. We'd have
libQt5Foo.so.1.0.0, for example.
Your email didn't address the problems I raised.
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Em qui 26 jun 2014, às 09:52:20, Stephen Kelly escreveu:
Therefore
the
major version must stay the same until Qt 6.
Why is it not acceptable?
Because Lars did not accept it.
Well, the solution is that you can rename the module altogether.
Quick 1 and Quick 2.
Em qui 26 jun 2014, às 09:52:57, Stephen Kelly escreveu:
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Proposal 1) All Qt modules must use the major version '5' for
consistency.
There's a difference between this is a Qt 5 library and this is a Qt
library with version
Hello,
At QtCS I briefly discussed with Lars my proposal to make a 'fixed' release of
qtenginio:
http://thread.gmane.org/gmane.comp.lib.qt.devel/17144/focus=17272
He did not accept it because situations could arise where a downstream
accidentally loads both libraries (eg through 3rd party
Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
This is of course the same situation that could arise if linking a program
with both Qt4Core and Qt5Core or anything. The problem is that we have this
problem within the lifetime of Qt 5.
Conclusion 1) Even if a Qt module has a
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
This is of course the same situation that could arise if linking a program
with both Qt4Core and Qt5Core or anything. The problem is that we have
this
problem within the
Em qua 25 jun 2014, às 17:57:35, Stephen Kelly escreveu:
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
This is of course the same situation that could arise if linking a
program
with both Qt4Core and Qt5Core or
39 matches
Mail list logo
