[Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Edward Welbourne]

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.