Shawn Rutledge (5 February 2020 14:14) > So I’m strongly in favor of continuing to do deprecations as long as > possible. A deprecation is not something that can break existing > functionality, so it’s no real risk as long as we’re sure we really > want to deprecate it.
A deprecation can break existing builds, for those who enable warnings-are-errors. Consequently, in the API change review, reviewers need to be able to see all deprecations, in order to be able to raise objections to any that are going to cause pain. I am well aware of how being kept from Qt 6 work makes it hard to discover the deprecations that'll be needed in 5.15 to support that Qt 6 work, once we get to it - I spent much of the last fortnight frantically getting those deprecations (and some API consolidations I noticed in the process) sorted out, precisely because I understood feature freeze as a hard cut-off. Dealing with it as such gives everyone a clearer view of what we're doing. I accept that the final Qt 5 release is special - and agree that the usual "we do time-based, so your change that missed FF only has to wait half a year" isn't as true as it would be at other times - but we do need to have visibility for changes to the API - including deprecations - so that our API change reviews can do their job properly. That includes clients of an API getting a chance to object to a deprecation. So please be sure to comment on API change reviews if you even suspect you may be about to decide to deprecate things that haven't yet been sorted out before feature freeze. API change reviewers need to know about them. We seem to have some diversity of opinion on how hard a cut-off the feature freeze is meant to be: that's a topic we need to discuss and answer, if we're to have release processes we can trust. On the one hand, the need for predictability in our release process means we need to have deadlines and stick to them. On the other hand, various practicalities make it necessary to have some flexibility. I think we need to revisit the incomplete QUIP 11 and actually document which things cut off when. https://codereview.qt-project.org/c/meta/quips/+/228450 Eddy. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
