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 be
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
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
> > release' of an entire module in that timespan?
>
> It mi
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 t
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 "un
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.
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.
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.
> >
>
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 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 fo
On 2014-06-30, Olivier Goffart 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 the Qt project, an
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 al
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. - An
On 6/30/14, 10:06 AM, "Olivier Goffart" 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, this is
an indi
On Monday, June 30, 2014 10:15:47 Giuseppe D'Angelo wrote:
> On 30 June 2014 09:50, Stephen Kelly 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, s
On 2014-06-30, Olivier Goffart 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
> of different
On 30 June 2014 09:50, Stephen Kelly 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 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 exact problem [0]. I would really
> like to avoid adding new stuf
On Monday, June 30, 2014 09:47:18 you wrote:
> On 30 June 2014 09:39, Stephen Kelly 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
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, bumpin
On 30 June 2014 09:39, Stephen Kelly 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 understood that with that s
On Friday, June 27, 2014 22:57:09 Giuseppe D'Angelo wrote:
> On 27 June 2014 22:10, Thiago Macieira 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 schem
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
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 li
On Friday, June 27, 2014 12:37:21 Jocelyn Turcotte wrote:
> When we switch to Qt 6 we'll also bump QtWebEngine to 2. QtWebEngine1
> depends on Qt5 and QtWebEngine2 depends on Qt6.
Why use 1 and 2? Why not use 5 and 6 for obviousness and consistency, and so
no mapping needs to exist in any brain o
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 r
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 ac
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 com
Em sex 27 jun 2014, às 22:57:09, Giuseppe D'Angelo escreveu:
> On 27 June 2014 22:10, Thiago Macieira 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 sch
On 27 June 2014 22:10, Thiago Macieira 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 might be a huge differ
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
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 re
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 guidelin
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 acceptabl
> -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 QtWebEngine 1.u.v
> with Qt 5.x.y, then QtWebEngine 1.u+1.v will
Hello,
we're soon going through this process with QtWebEngine, so let's use this
as a concrete example. We can possibly use this as a guideline for future
Qt module as well.
We already went through some discussion, and I'll share our plan here, but
nothing is set in stone so let's see if we need
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 a
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
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 altoge
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.co
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
> ever
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 cou
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 Qt5C
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 withi
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 dis
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 tr
46 matches
Mail list logo
