[Development] Deprecation/removal model going into Qt 6

[Giuseppe D'Angelo]

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 series, doing what we can for Qt 6.0 (and doing it right) is the
>> only option we have.
>>   
>> Perhaps we can care less about those compatilbiity promises; I personally
>> think the "big bang every 7 years” is not giving us nearly as much as it
>> costs; a continuous flow of carefully managed changes to either would
>> perhaps make it rather easier for developers to follow along, and remove
>> those big, painful porting headaches (unless you didn’t follow the Qt
>> releases, in which case it’s just as bad as it is today).
> 
> 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 doing this kind of
> releases.

But this is simply impossible. It would require an infinite development 
bandwidth, and at a certain point, may constrain development too much. 
Ballast (obsolete functionality, for various degree of "obsolete") has 
to be dropped from time to time, causing API breaks. The question in 
this thread is how to manage those API breaks to be as painless as possible.


  Changes such as deprecating or incompatibly rewriting a data
> structure as central as QList (as seems to be already consensus for Qt 6)
> are just a major disservice to developers. 

... exactly, because it's an API break. How can we minimize the damage?


> ABI breaks such as the QString
> SSO (that also seems to be already consensus for Qt 6) are also unnecessary
> and probably also counterproductive in some use cases.

What? Why?


> Your proposal to break ABI at every 6.x minor release would be an absolute
> nightmare for distributors. 

I personally interpreted "continuous flow of carefully managed changes" 
as "small" API breaks, not (just) ABI breaks.

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190602/0a3048af/attachment.bin>