Qt Creator Submission Policies

Branches

There are basically three types of branches that we use in Qt Creator development

• Feature branch: Branch created for development of a specific larger feature (or other code changes) without disturbing 'regular' Qt Creator development (e.g. wip/clang)
• Master branch: Branch where new features and other 'major' things are pushed (i.e. master)
• Minor version/release branch: Branch that will become the next minor release, will be branch off from Master branch at time of feature freeze for that version (e.g. 2.4)

We don't create branches for patch releases. The minor version branch is regularly merged up to Master.

Feature Branches

Feature branches can be created for the development of code that the corresponding maintainer deems useful and potentially fit for merging into master when it is ready. Reasons for creating a feature branch instead of developing on a separate git repository, and posting the complete patch for review&merge after it is finished, can include but is not limited to

• development in cooperation of several people (CLA requires submission of individual commits to gerrit for each contributor)
• large amount of code expected that would benefit from the additional reviews in between
• better visibility of the work

Life time of feature branches is at the maintainer's discretion, i.e. if a feature branch is created at all, and when it will be removed again (e.g. when the code is ready for merge, or when the code is no longer developed).

Feature branches follow the naming wip/short-but-descriptive-name and should be announced on the mailing list.

Release Branch States

The release branches go through several states, which are described here in chronological order:

• In feature freeze: Initial state of a release branch. No features are added anymore. Bug-fixing mode.
• In soft string freeze: Together with beta release. Translatable strings and the UI (layouts etc) should be mostly finished, translators should start. Last chance for fixing strings and resolving UI issues, but with as little impact as possible.
• In string freeze: Between soft string freeze and release candidate. Translatable strings are not to be changed anymore. Translators go full steam ahead. UI freezes as well. Exceptions must be checked with the documentation team, and the Localization mailing be informed about changes. At this point we also go into soft API freeze.
• Freezing: Shortly before release candidate. Only P0/1 fixes (or high "severity / risk" ratio), translations, test and documentation fixes are allowed. Fixes must be checked with release manager. At this point we also go into hard API freeze.
• Frozen: After a potential patch release. No more changes go into the branch, there is no release planned to be done from this branch anymore.