<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
One year for a major Qt release and then break API?<br>
</div>
</blockquote>
<div>
<div id="appendonsend"></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I didn't say that.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The thing is that there will be much less changes for one year. It means that you need to do less job to switch a version. I hope it also will lead to more careful feature planning and API design. With shorter release cycle it also will be possible to faster
 adopt new best practices, approaches, and language standards. Especially for new API. All of these things make developers more productive and make it easier to hire a new people.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Just think when Qt and its user could make use of such a handy things like coroutines, ranges, modules, concepts and so on. In 3-5 years, with the current approach. Probably. These features is not something trendy, they are the real things that help solving
 regular software engineering tasks faster and more efficient.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex;">
How many people have you seen that use Qt as a means to get *their*<br>
problem solved, and how many of them prefered adapting their code to<br>
Qt API changes over working on there own code?<br>
</blockquote>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I guess this is a rhetorical question, right? The situation is the same with a refactoring. There are many books about it. All I want to say is that there is always should be a balance.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex;">
How often do you think we can play this game until people look for<br>
something they consider more stable?<br>
</blockquote>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Moving to one year release approach doesn't equal to make Qt less stable.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size: 11pt;" data-ogsc=""><b>From:</b> André Pönitz <apoenitz@t-online.de><br>
<b>Sent:</b> Thursday, April 23, 2020 17:52<br>
<b>To:</b> Vitaly Fanaskov <vitaly.fanaskov@qt.io><br>
<b>Cc:</b> Simon Hausmann <Simon.Hausmann@qt.io>; development@qt-project.org <development@qt-project.org><br>
<b>Subject:</b> Re: [Development] Proposal: Deprecate QVector in Qt 6</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On Thu, Apr 23, 2020 at 12:25:33PM +0000, Vitaly Fanaskov wrote:<br>
>    I think we should completely remove QList in Qt6. It was planned<br>
>    before, as far as I remember. The main reason is to be consistent with<br>
>    STL wording and do not violate POLA too much.<br>
> <br>
>    I read the entire discussion, and I'd like to say this one more time:<br>
>    we don't have to fight the consequences. Better to eliminate a cause.<br>
>    There always will be a functionality to deprecate. There always will be<br>
>    controversial APIs, that, for example, contain a hard-coded type<br>
>    information in the name (e.g. "windowList()" instead of "windows()").<br>
>    Why not think about it instead? Today it QVector vs. QList, tomorrow<br>
>    something else...<br>
> <br>
>    We can at least shorten release cycle to one year.<br>
<br>
One year for a major Qt release and then break API?<br>
<br>
How many people have you seen that use Qt as a means to get *their*<br>
problem solved, and how many of them prefered adapting their code to<br>
Qt API changes over working on there own code?<br>
<br>
How often do you think we can play this game until people look for<br>
something they consider more stable?<br>
<br>
>    Provide clang-based tools to (semi-)automatically port users' code<br>
>    bases to a new version of Qt.<br>
><br>
>    These tools might either fix a code or at<br>
>    least add a comment in potentially problematic places where a user<br>
>    should correct the code. A developer who changes API should also<br>
>    implement a rule for these tools.<br>
<br>
This magic tool comes up over and over again, still no-one "just did it".<br>
Maybe because it's not *that* trivial after all, maybe because doing that<br>
actual porting ends up in real work, which is  much less fun than just<br>
deciding that something needs to be changed, maybe something else.<br>
<br>
Really: All this talk "this is bad, should be done differently, and<br>
then it is better" would be much easier to believe if they were accompanied<br>
by patches that implements that change for all of Qt. Or all of KDE.<br>
<br>
Andre'<br>
</div>
</span></font></div>
</div>
</body>
</html>