[Development] Qt 5.13 feature freeze is getting closer

Tuukka Turunen tuukka.turunen at qt.io
Thu Jan 17 15:31:47 CET 2019


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.  



´╗┐On 17/01/2019, 16.11, "Edward Welbourne" <edward.welbourne at qt.io> 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.

More information about the Development mailing list