On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote:
> Well, something has to give. Either
> a) Qt can never remove superseded APIs and classes (which is what
> you suggested previously) and will eventually collapse under its own
> weight, or
> b) Distributors have to deal with the fact th
On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote:
> I also managed to get that done with a <10 lines of "plain cmake":
>
> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05
> 7/src/CMakeLists.txt#L46-L54
Yup, I figured with CMake it would be possible. But I'm t
On Sunday, 2 June 2019 16:39:24 PDT Kevin Kofler wrote:
> PS: Imagine the outcry and havoc if Intel decided to tell you, e.g.: "Sorry,
> x87 floating-point is obsolete and hard for us to maintain, we will drop it
> from our next generation of CPUs and force everybody to port their software
> to SSE
On Sunday, 2 June 2019 15:29:11 PDT Manuel Bergler wrote:
> > Repeat after me: inline namespaces are not a tool to retain ABI.
>
> Of course they are. That's the reason they were introduced [0]: To
> allow symbol versioning as part of the language without having to
> write linker scripts, thus ena
On 01.06.19 17:56, Thiago Macieira wrote:
On Saturday, 1 June 2019 03:46:34 PDT André Pönitz wrote:
I am getting mildly irritated by those ongoing suggestions (not just
yours) to use anything but Qt to get stuff done, even Qt's own tasks.
It's sending an odd message.
Sure, one can pull e.g. any
Am Mo., 3. Juni 2019 um 02:21 Uhr schrieb Konstantin Shegunov
:
>
> On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote:
>>
>> Why should software be different?
>
>
> It shouldn't, as already pointed out. That's why well behaved libraries try
> to keep compatibility in some reasonable margins.
>
On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote:
> Why should software be different?
It shouldn't, as already pointed out. That's why well behaved libraries try
to keep compatibility in some reasonable margins.
To throw one more stone here - are you willing to backport patches from
latter m
Am Mo., 3. Juni 2019 um 01:35 Uhr schrieb Kevin Kofler :
>
> Manuel Bergler wrote:
> > And this is where we come full circle :) Yes, FOSS needs to port, so
> > we should make porting as easy as possible. In particular, there
> > shouldn't be too many breaking changes all at once as that would make
Kevin Kofler wrote:
> But we do have the expectation that the CPU will still run our 10-year-old
> code without having to recompile it. Modern CPUs are backwards-compatible
> with restrictions (e.g., you cannot use 16-bit code from a 64-bit OS, at
> least not without dangerous hacks) all the way to
Manuel Bergler wrote:
> And this is where we come full circle :) Yes, FOSS needs to port, so
> we should make porting as easy as possible. In particular, there
> shouldn't be too many breaking changes all at once as that would make
> porting a multi-month project. Instead, spread out the breaking
>
Am Mo., 3. Juni 2019 um 01:20 Uhr schrieb Konstantin Tokarev
:
> 03.06.2019, 02:10, "Manuel Bergler" :
> > Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler
> > :
> >
> >> What you call "obsolete functionality" is functionality that existing code
> >> relies on and rightfully expects to re
Manuel Bergler wrote:
> I fully disagree with the sentiment in that blog post. If you don't
> want to port, fine, but then also use whatever version of Qt you were
> using before and don't try to use the latest and greatest.
But that is a luxury we simply do not have in the Free Software world whe
03.06.2019, 02:10, "Manuel Bergler" :
> Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler
> :
>
>> What you call "obsolete functionality" is functionality that existing code
>> relies on and rightfully expects to remain there.
>>
>> I'd rather get fewer (or even no) new features than los
Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler :
> What you call "obsolete functionality" is functionality that existing code
> relies on and rightfully expects to remain there.
>
> I'd rather get fewer (or even no) new features than losing existing ones.
>
> See also Boudewijn Rempt's blo
Am So., 2. Juni 2019 um 18:56 Uhr schrieb Lisandro Damián Nicanor
Pérez Meyer :
>
> Hi! With my Debian maintainer hat on:
>
> On Sun, 2 Jun 2019 at 05:21, Manuel Bergler wrote:
> >
> > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler
> > :
> >>
> >> Volker Hilsheimer wrote:
> [snip]
> >> Yo
Am So., 2. Juni 2019 um 19:18 Uhr schrieb Thiago Macieira
:
>
> On Sunday, 2 June 2019 01:20:51 PDT Manuel Bergler wrote:
> > First of all, Qt itself
> > could make use of inline namespaces to ship several version of the same
> > classes in the same binary while keeping source compatibility.
>
> R
Giuseppe D'Angelo via Development wrote:
> Il 01/06/19 23:34, Kevin Kofler ha scritto:
>> But the problem for developers is NOT the 5.x releases that do not break
>> the API. Those are great! The problem is those n.0 releases that DO break
>> the API. And the solution there would be to just stop d
Manuel Bergler wrote:
> I myself don't mind the 2 weeks it took so far to upgrade from Qt 5.9 to
> Qt 5.12 in our project, that's just the cost of progress...
I guess one of the reasons that you are feeling more migration pain than the
FOSS projects is because you skip all the non-LTS branches, w
Lisandro Damián Nicanor Pérez Meyer wrote:
> Boost is **exactly** the best example of why Qt should not go the same
> route. It's totally problematic to have more than two stacks around,
> and we **will** have Qt5 and Qt6 for a long time.
In fact, Fedora even still ships Qt 3 and Qt 4 and they are
I'm a bit late to this game, but ...
> I don’t see why you’d want to remove the switch for Qt 6.
> It would be a porting help for application developers.
Application developers will not build their own Qt, but rely on the QList with
the switch their Qt and Qt-using 3rd party libraries are built
On 2019-05-23, Lars Knoll wrote:
I'm a bit late to this game, but ...
> I don’t see why you’d want to remove the switch for Qt 6.
> It would be a porting help for application developers.
Application developers will not build their own Qt, but rely on the
QList with the switch their Qt and Qt-us
On Sun, 2 Jun 2019 at 13:59, Lisandro Damián Nicanor Pérez Meyer
wrote:
>
> On Sun, 2 Jun 2019 at 10:10, Allan Sandfeld Jensen wrote:
> [snip]
> > >
> > I have no problem with breaking ABI more often but allowing it in every
> > minor
> > releases probably goes to far. Perhaps every second LTS (
Il 31/05/19 15:24, Volker Hilsheimer ha scritto:
Hey Guiseppe,
That is my understanding as well. Yes, 5.15 will be an LTS, and assumed to be
the last feature release in Qt 5.
Thanks for confirming my reading.
I guess that the idea is that the port to Qt 6 can then happen in multiple
s
On Sunday, 2 June 2019 01:20:51 PDT Manuel Bergler wrote:
> First of all, Qt itself
> could make use of inline namespaces to ship several version of the same
> classes in the same binary while keeping source compatibility.
Repeat after me: inline namespaces are not a tool to retain ABI.
They may
On Sunday, 2 June 2019 07:30:11 PDT Jean-Michaël Celerier wrote:
> - boost has the exact same ABI stability issue (e.g. no ABI / API stability
> guarantees at all) and yet distros seem to manage all the C++ software
> which uses it without much problems.
Please send your distro packager some Chris
Hi!
On Sun, 2 Jun 2019 at 11:31, Jean-Michaël Celerier
wrote:
>
> > If existing package of application cannot be rebuilt from source with
> > updated
> Qt version, it's a sure no-go for distibution. Either Qt update will be
> blocked, or
> application will be thrown away (or application will b
On Sun, 2 Jun 2019 at 10:10, Allan Sandfeld Jensen wrote:
[snip]
> >
> I have no problem with breaking ABI more often but allowing it in every minor
> releases probably goes to far. Perhaps every second LTS (every 3 years), might
> be better.
That would work as long as related applications (moc,
Hi! With my Debian maintainer hat on:
On Sun, 2 Jun 2019 at 05:21, Manuel Bergler wrote:
>
> Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler
> :
>>
>> Volker Hilsheimer wrote:
[snip]
>> Your proposal to break ABI at every 6.x minor release would be an absolute
>> nightmare for distributor
On 6/2/19, 12:02 PM, "Stottlemyer, Brett (B.S.)" wrote:
This discussion reminds me of Python 2 vs. Python 3, and I think there are
some important lessons to consider from Python.
FYI, I know Qt has been through version updates as well, and Qt 4 -> Qt 5 was
not that long ago. For me, QML o
On 6/1/19, 9:10 AM, "Development on behalf of Philippe"
wrote:
I second a recent quote from Lars Knoll :
> Qt has always had a somewhat different philosophy. Make C++ easy to use,
> no need to use Java. The fact is that 95% of the source code our users
>write will not be per
> - People nowadays will just use the flatpak / appimage / snap / whatever
I can see how that works for single-binary GUI applications.
Do you know any example for a complex Qt-based multi-binary (preferably
command line usage) application that does that well?
__
02.06.2019, 17:30, "Jean-Michaël Celerier" :
>> If existing package of application cannot be rebuilt from source with
>>updated
> Qt version, it's a sure no-go for distibution. Either Qt update will be
> blocked, or
> application will be thrown away (or application will be somehow patched by
Il 02/06/19 16:07, Konstantin Tokarev ha scritto:
That's why I suggested using inline namespaces. Then even if an
application no longer compiles with the new version of Qt it can still
link against it.
If existing package of application cannot be rebuilt from source with updated
Qt version, it's
> If existing package of application cannot be rebuilt from source with
updated
Qt version, it's a sure no-go for distibution. Either Qt update will be
blocked, or
application will be thrown away (or application will be somehow patched by
other
people, without you even knowing about that)
- Peopl
02.06.2019, 17:03, "Manuel Bergler" :
> Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev
> :
>> 02.06.2019, 16:34, "Manuel Bergler" :
>> > Due to Hyrum's law [0], even with stricter guarantees there will
>> > always be someone for which migration is a non-trivial amount of work.
>>
Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev
:
>
>
>
> 02.06.2019, 16:34, "Manuel Bergler" :
> > Due to Hyrum's law [0], even with stricter guarantees there will
> > always be someone for which migration is a non-trivial amount of work.
> > The only way to avoid that is to change no
02.06.2019, 16:34, "Manuel Bergler" :
> Due to Hyrum's law [0], even with stricter guarantees there will
> always be someone for which migration is a non-trivial amount of work.
> The only way to avoid that is to change nothing, ever. I personally
> also don't understand why people would expect g
> Manuel Bergler wrote:
> > Right now, even though the API and ABI are stable, I have never seen an
> > update to a new minor version of Qt5 that did not require source changes
> > due to changed behavior,
>
> Well, that depends pretty much on the individual project (how large it is
> and what part
Il 01/06/19 23:34, Kevin Kofler ha scritto:
Volker Hilsheimer wrote:
The overall goal here is to make sure that we don’t have to carry poorly
designed architecture or APIs around with us throughout the Qt 6 series,
and as long as we care about binary and source compatibility within a
major serie
On Sonntag, 2. Juni 2019 10:20:51 CEST Manuel Bergler wrote:
> Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <
>
> kevin.kof...@chello.at>:
> > Volker Hilsheimer wrote:
> > > The overall goal here is to make sure that we don’t have to carry poorly
> > > designed architecture or APIs aroun
> On 1 Jun 2019, at 16:12, Alberto Mardegan wrote:
>
> On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
>> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
>> three years maintenance. We are not expecting lots of people to jump
>> on Qt 6.0 anyway (because .0, and not an LTS rele
Il 01/06/19 23:17, Kevin Kofler ha scritto:
Indeed. One case in point: All this confabulation about move constructors
etc. misses the point that the gain of moving compared to shallow copying
with CoW is typically irrelevant for those 95% of non-performance-critical
code. But using explicit move
Manuel Bergler wrote:
> Right now, even though the API and ABI are stable, I have never seen an
> update to a new minor version of Qt5 that did not require source changes
> due to changed behavior,
Well, that depends pretty much on the individual project (how large it is
and what parts of Qt it u
Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <
kevin.kof...@chello.at>:
> Volker Hilsheimer wrote:
> > The overall goal here is to make sure that we don’t have to carry poorly
> > designed architecture or APIs around with us throughout the Qt 6 series,
> > and as long as we care about bi
44 matches
Mail list logo
