[Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Volker Hilsheimer]

> On 19 Mar 2021, at 14:34, Roland Hughes <roland at logikalsolutions.com> wrote:
> 
> 
> On 3/19/21 7:51 AM, Volker Hilsheimer wrote:
>>> On 19 Mar 2021, at 12:12, Roland Hughes <roland at logikalsolutions.com> wrote:
>>> 
>>> 
>>> 
>>> On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
>>>> Il 18/03/21 12:41, Christian Gagneraud ha scritto:
>>>> 
>>>>> My main grief is that Qt doesn't seem to care about C++.
>>>>> What was their last contribution to the standard?
>>>>> 
>>>> Apart from hiring the ex-chair of the WG21 Evolution Working Group?
>>>> 
>>>> (Can we stop with the FUD please?)
>>>> 
>>> Can we stop the willy-nilly deletion of existing convenience methods currently used in products in the field?
>>> -- 
>>> Roland Hughes, President
>> Hey Roland,
>> 
>> Giving Qt 6 a leaner API was a conscious decision in many cases to avoid the API from bloating too much. We can add convenience wrappers and overloads when we see that they are really needed.
>> 
>> We might have gone a bit far in some cases, but the porting experiences I’ve read so far suggest that by and large it has been a rather decent experience.
>> 
>> Do you have any particular classes in mind?
>> 
>> Volker
>> 
> I'm sure the person who was complaining repeatedly to Giuseppe will pipe up if they are still using Qt. That was a long thread in here last year. It lead to other long threads.
> 
> You cannot remove existing functionality without surveying the user base to find out if it is used. That person took a big hit with a lot of needless retesting and coding because of a willy-nilly removal.
> 
> Once you ship it, you can't remove it, until __after__ it dies on the field. Doesn't matter what "it" is. This is called product stability. I do not know if it was an FDA regulated product that impacted. I do know that if it was FDA regulated the odds of them being able to slip it through the "minor enhancement" (don't remember the official name) testing and approval path with that level of modification would be slim. That would mean lots of additional expense for them and everyone else impacted by the removal.
> 
> This also lead to a lengthy discussion about API stability. You can also find that in the archives for last year and probably in 2019 as well.
> 
> For the SAFETY world where human/animal life is at Risk, LTS is roughly 20 years (over 30 in some markets) and STS (Short Term Support) is 7-10 years.
> 
> Thinning out the API may have been a conscious decisions, but I never saw any messages on this list about things you were thinking about killing. Granted I get this in digest form and mostly skim the subjects for something of interest to me. Judging from the shock and length of that previous discussion nobody on here saw any such messages either. From a customer base perspective these decisions were made in a vacuum and are helping to speed the complete abandonment of Qt.


Ok. API stability on the one hand, and keeping things maintainable and un-bloated over a long time on the other, is of course a tradeoff. Different industries will have different preferences, but the path we have chose for Qt over the last 25 years seems to not have been completely wrong, even for folks building safety critical systems.

That there are long threads on controversial topics is often a good thing. esp if they are followed by code contributions from the people that care. Many of the discussions we had last year about e.g. the APIs of container and string classes (most of those on the development list where the development OF Qt is discussed [1]) have definitely resulted in better decisions for Qt 6.0.

Volker

[1] https://lists.qt-project.org/listinfo/development