One year for a major Qt release and then break API? I didn't say that. 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. 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.
How many people have you seen that use Qt as a means to get *their* problem solved, and how many of them prefered adapting their code to Qt API changes over working on there own code? 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. How often do you think we can play this game until people look for something they consider more stable? Moving to one year release approach doesn't equal to make Qt less stable. ________________________________ From: André Pönitz <apoen...@t-online.de> Sent: Thursday, April 23, 2020 17:52 To: Vitaly Fanaskov <vitaly.fanas...@qt.io> Cc: Simon Hausmann <simon.hausm...@qt.io>; development@qt-project.org <development@qt-project.org> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 On Thu, Apr 23, 2020 at 12:25:33PM +0000, Vitaly Fanaskov wrote: > I think we should completely remove QList in Qt6. It was planned > before, as far as I remember. The main reason is to be consistent with > STL wording and do not violate POLA too much. > > I read the entire discussion, and I'd like to say this one more time: > we don't have to fight the consequences. Better to eliminate a cause. > There always will be a functionality to deprecate. There always will be > controversial APIs, that, for example, contain a hard-coded type > information in the name (e.g. "windowList()" instead of "windows()"). > Why not think about it instead? Today it QVector vs. QList, tomorrow > something else... > > We can at least shorten release cycle to one year. One year for a major Qt release and then break API? How many people have you seen that use Qt as a means to get *their* problem solved, and how many of them prefered adapting their code to Qt API changes over working on there own code? How often do you think we can play this game until people look for something they consider more stable? > Provide clang-based tools to (semi-)automatically port users' code > bases to a new version of Qt. > > These tools might either fix a code or at > least add a comment in potentially problematic places where a user > should correct the code. A developer who changes API should also > implement a rule for these tools. This magic tool comes up over and over again, still no-one "just did it". Maybe because it's not *that* trivial after all, maybe because doing that actual porting ends up in real work, which is much less fun than just deciding that something needs to be changed, maybe something else. Really: All this talk "this is bad, should be done differently, and then it is better" would be much easier to believe if they were accompanied by patches that implements that change for all of Qt. Or all of KDE. Andre'
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
