Hi,
Yes, I was thinking that we could use a slightly similar approach for the new
modules as we do for the API change reviews (to the extent applicable,
considering we do not have anything to automatically compare to etc). That
said, we may be too close to Qt 5.13 feature freeze to fully do that for all
the candidate new modules before FF. Perhaps the most viable approach would be
to do the review fixes before Beta 1 release - and in case not adequately fixed
to be a technology preview, drop it out before the Beta 1. We should also
decide what is the policy we use for Qt 5.14 onwards regarding timing of API
reviews and add to https://wiki.qt.io/Qt_5_Feature_Freeze.
Yours,
Tuukka
On 17/01/2019, 16.11, "Edward Welbourne" <[email protected]> wrote:
Tuukka Turunen (17 January 2019 15:00)
> I think best would be to do the API review in codereview tool as
> mailing lists are of limited efficiency in this purpose. Based on the
> API review we can then decide if the module is ready to be part of Qt
> 5.13 as TP or not. For the existing modules we do the API review a bit
> later,
As I suspect you're thinking of the API reviews I create in the run-up
to a release, I feel obliged to point out these are really API *change*
reviews. Without a prior release to compare against, the tool for that
doesn't know how to report anything. You need an actual review of the
whole API, not just some recent changes to it.
> but for the proposed new modules we could well do it already now - if
> not recently completed.
I don't know of an established process for API review (that reviews the
whole of an API, not just what's lately changed). We surely need one
(and it might not hurt to do them to old existing APIs, also, from time
to time), in particular for use when considering a new module.
Eddy.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
