> On 28 Apr 2020, at 13:39, Edward Welbourne <[email protected]> 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 _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
