[Development] Qt 6.0.0 initial schedule

[Volker Hilsheimer]

> 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
>> mess.
> 
> 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 ?
> 
> 	Eddy.


We discussed this at Qt Contributors Summit 2019 and developed some ideas:

https://wiki.qt.io/Qt_Contributors_Summit_2019_-_API_Review_Process

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.” [1]

[1] http://quips-qt-io.herokuapp.com/quip-0001.html


Volker