[Development] Qt 6.0.0 initial schedule
volker.hilsheimer at qt.io
Tue Apr 28 16:45:36 CEST 2020
> On 28 Apr 2020, at 13:39, Edward Welbourne <edward.welbourne at qt.io> wrote:
> Jani Heikkinen (27 April 2020 14:05) wrote:
>> And in addition to these normal release milestones we need to have
>> earlier milestone (Structure and platform freeze) at the end of June
>> (30.6.2020, just before summer holidays) to lock down modules, target
>> platforms etc for the release. In that milestone at least
>> - New cmake based builds needs to be in place for modules which will
>> be in Qt 6.0.0 release
>> - All bigger architectural changes needs to be implemented.
>> - Target platforms needs to be in CI
>> (- Something else?)
>> All that will make sure we can create packaging configurations & start
>> delivering regular snapshots early enough for Qt 6.0.0 (with correct
>> set of modules etc). And this will also ensure all modules can adapt
>> to those big architectural changes before FF. If we don't have this
>> extra milestone we will end up the situation where most of (big)
>> changes will be available just before FF and that will cause huge
> Sounds like a useful sanity-check-point; it should help us notice early
> anything that some of us think we have consensus on and others might be
> surprised by - or surprised it's gone forward, given the objections they
> raised earlier; or that they'd simply not even heard about.
> Our existing process's first point has been feature-freeze and that's
> when we've got API change review scheduled for; to what extent do folk
> think it may be worth starting the API change review earlier, for
> example at this new Structure & Platform milestone ? Might it make
> sense to have an initial "overall, don't fuss about details" API change
> review in June, ready for this milestone, as a precursor to the full API
> change review process, whether that be following S&P or after FF ?
> We clearly also need to think about how to do API reviews (not change,
> but the actual API as a whole), particularly for things that have
> changed or been added, but possibly also for other things in case review
> reveals they perhaps *should* change. I don't pretend to know what
> process makes sense for that. Any suggestions ?
We discussed this at Qt Contributors Summit 2019 and developed some ideas:
Reviewing APIs, and even more so the overall design of a framework of classes, needs to be part of developing those APIs and classes.
The process of reviewing the header files for technical correctness and for compliance with design principles is a poor substitute for an API design review. I would even go as far as say that doing a design review for a comprehensive framework of classes once the code has alread been written is too late. In those cases I find it more valuable to discuss things based on a short design document in plain English. This is also what QUIPs were supposed to be about:
"An Implementation QUIP describes a new feature, module or implementation for Qt. QUIPs describing API changes as well as QUIPs describing the introduction or removal of modules are also Implementation QUIPs.” 
More information about the Development