On 5 Feb 2020, at 13:04, Jani Heikkinen <[email protected]<mailto:[email protected]>> wrote:
We are doing time based releases so if new feature misses the deadline there will be next one coming after few months. It might be quite long time for unique feature but on the other hand it isn't really that long… It’s the end of the Qt 5 series, so time to the next Qt 5 release after this one is infinite (it won't happen at all). Users won’t switch to Qt 6 anytime soon. Missing functionality will hurt them more than usual. I’m not talking about pie-in-the-sky ideas, but features that are close to done and were promised for a long time already; and even more so, missing features that are blocking imminent releases of other modules that were promised, or already paid for. Failing to get all the deprecations in place for things we want to remove in Qt 6 will also hurt users a lot. So I think we need to be more flexible than usual about getting those in. And those of us who had real work to add features in 5.15 have not yet had time to work on the sort of Qt 6 things that could result in the need to add deprecations in 5.15. (And that will probably go on for a few more weeks, too.) If you argue against getting more deprecations in place in 5.15, then you are also implicitly arguing in favor of having more SC breaks in Qt 6. So I’m strongly in favor of continuing to do deprecations as long as possible. A deprecation is not something that can break existing functionality, so it’s no real risk as long as we’re sure we really want to deprecate it. The exact timing of the 5.15 release could even slip more than usual; what will it really matter? For once I think we should be concerned more about quality than timing. As long as we get 5.15.0 out within the first half of the year, we will satisfy our duty to the almighty #%#$% schedule.
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
