Submit Policies

Submit Policies

We develop and release several versions of Qt in parallel. Basically we have three different types of releases: major, minor and patch. A Major release has many new features and refactoring of existing ones, it can even break binary and source compatibility. A Minor release has some new features, and a Patch release has no new features and is a drop-in replacement of a previous Qt release.

Each of these products is developed in their own branch and each of these branches has a submit policy attached to it. A submit policy gives guidelines to what can go into a branch or not. In a typical lifecycle a release is elevated into branches with more and more restrictive submit policies. Typically something like:

<span class="caps">PLANNED</span> —&gt; <span class="caps">FREEZING</span> —&gt; <span class="caps">FROZEN</span> —&gt; <span class="caps">LOCKED</span> —&gt; <span class="caps">CLOSED</span>

Policy	Summary	Example
OPEN	anything goes	Personal or team repository
PLANNED	only planned features	qt/master
FREEZING	reviews encouraged, features complete, bug fixing only	qt/4.6
FROZEN	reviews enforced, regression fixes	qt/4.5
LOCKED	no submits except by owner	qt/4.4
CLOSED	no submits, branch is dead	qt/3.1

OPEN

Any change is allowed. Such branches are usually used for research. Large chunks of code can be developed and tested here without affecting other projects. When the code is ready, it can be integrated into Qt. The recommended location is to put this in either a personal repository or a team shared repository.

PLANNED

Pre-release state. This branch is not yet feature complete, and will be moved into the FREEZING state once new features are done. Only planned features and bugfixes should go in there.

FREEZING

Pre-release state.

• Code reviews are not required but strongly encouraged. For really simple changes, you can still use your head and override this with a

  RevBy: Trust me
  

• No new features, bug fixing only
• New API may still change

FROZEN

Post-release state. The API included in a frozen branch is also frozen, meaning that it cannot change in source or binary incompatible ways, not even in other, less strict branches. Only certain types of changes are allowed, after peer-review by one other colleague. These changes include:

Qt:

• regressions from earlier releases
• platform specific build fixes
• platform specific bugs (broken on one platform, works on all others)
• embarrassingly broken painting
• data corruption (e.g. incorrect .ui-files or generated code)
• crashes
  • memory corruption
  • uninitialized variables
  • missing null pointer checks
  • infinite recursions
• race conditions
• licensing issues (non-GPL files in GPL release, wrong license text etc.)
• important documentation fixes
• fixes implementation of new functionality that is not according to the design/docs

After discussion with release manager:

• crucial usability issues for classes and applications (exception not rule)

New features are considered new for one minor release.

Every change in a frozen branch should have a testcase associated with it. Preferably an auto-test otherwise a manual testcase.

The git commit message must follow the format given in the .commit-template file found in the root of the Qt tree.

The reviewers should always check that the above conditions are met.

LOCKED

The branch is locked. This typically means the release management is testing the branch and only they can submit to it.

CLOSED

Post-release state. No more release will be made from this branch. No changes to a closed branch are allowed. The only exception to this rule is when required by an extended support contract by a major customer.

When in doubt, if the bug doesn’t fit any of the above categories, you send a mail to <NEEDS_CURRENT_ADDRESS> to discuss the issue. You can also ask on the

#qt-labs

IRC channel on freenode. (For a full list of IRC channels of interest to Qt developers, see http://wiki.qt.io/OnlineCommunities )

Categories:

• Developing_Qt
  • Guidelines