[Development] Important: Qt 5 freeze

[lars.knoll at nokia.com]

Hi everybody,

it's been now a little over two weeks since we announced the feature
freeze. But I am still seeing lots of discussions about refactoring of
code, API additions and other things that I'd count mostly as feature
development. All of these changes are nice in principle, but they do not
bring us closer to a releasable Qt.

Quite to the opposite, many of these changes are actually bringing us
further away from having something releasable. So let's be clear here: We
need to stop with these now and focus on stability and bug fixing if we
are to ship Qt 5.0 as planned.

At this stage, we need to make sure we can all focus on bug fixing and for
that we need to be more conservative in what kind of changes we do.

Every source incompatible change is disruptive for people working in
downstream repositories (declarative, etc.). Even binary incompatible
changes
cause us to loose a lot of time. Every time someone breaks binary
compatibility in qtbase, people are forced to recompile all of their libs.
This easily takes an hour. Multiply this with the number of developers
working on the different Qt modules and we're talking several man weeks of
lost time.

To avoid these problems, let's now change our process slightly. We will
use a new branch of qtbase in gerrit called api_changes for anything that
is more than a bugfix. This branch is also CI controlled, and I'll merge
from master into the branch regularly. At well defined times we'll them
merge api_changes back to master. Other repositories such as declarative
can create a similar branch if needed.

Here's some guidelines about where changes should go:

1. Bug fixes that are source and binary compatible
	--> master
2. Small API additions that fill a gap, are SC and BC and have no side
   effects
	- e.g. C++11 additions
	--> master
3. BIC, but SC changes
	- Please think a couple of times whether this is really needed
	--> api_changes
4. SIC changes of new functionality
	- Aim to provide the old API as QT_DEPRECATED methods to avoid
	  disrupting downstream
	- #ifdef them with QT_5_0_COMPAT. We can add this macro to global.h
	  for now, remove again before we ship 5.0
	--> api_changes
5. SIC changes of Qt 4.x functionality
	--> Sorry, won't go in

Let's be very strict about the above policies, otherwise we'll have a very
difficult time to get 5.0 out.

We have a couple of exceptions listed in QTBUG-20885 to the above rules.
These are:

* new regexp classes
* remove QSettings
* container branch
* new QMap
* codecForCStrings/codecForTr removal
* Finish platform specific parts and gain feature parity with 4.x
* QUrl rewrite
* QDeclarative -> QQml name change
* qreal decision

Deadline for finishing these features is end of next week. Stuff that's
not done by then will not make it into 5.0. All of these features should
go into the api_changes branch; I'll write emails about them all
separately so we don't have large discussions about them in this thread.

Please don't even think about other features before we're going towards
5.1.

Instead, there's lots of work that we need to do that is just as important
but doesn't affect the APIs as much. We need to fix lots of bugs. Let's
look at memory consumption of Qt apps and optimize that. Let's work on
improving performance. And let's work on fixing the remaining gaps we have
against Qt 4.x

Cheers,
Lars