[Development] Qt 6.0.0 initial schedule

Edward Welbourne edward.welbourne at qt.io
Tue Apr 28 13:39:27 CEST 2020


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.


More information about the Development mailing list