Qt Creator Submission Policies: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (10 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
==Branches== | [[Category:Tools::QtCreator]] | ||
== Branches == | |||
There are basically three types of branches that we use in Qt Creator development | 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''') | |||
* '''Feature branch:''' Branch created for development of a specific larger feature (or other code changes) without disturbing | * '''Master branch:''' Branch where new features and other 'major' things are pushed (i.e. '''master''') | ||
* '''Master branch:''' Branch where new features and other | |||
* '''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''') | * '''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 | We don't create branches for patch releases. | ||
The minor version branch is regularly merged up to Master. | |||
==Feature Branches== | == 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& | 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 ( | * 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 | * large amount of code expected that would benefit from the additional reviews in between | ||
* better visibility of the work | * better visibility of the work | ||
Life time of feature branches is at the | 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. | Feature branches follow the naming '''wip/short-but-descriptive-name''' and should be announced on the mailing list. | ||
==Release Branch States== | == Release Branch States == | ||
The release branches go through several states, which are described here in chronological order: | The release branches go through several states, which are described here in chronological order: | ||
| Line 27: | Line 29: | ||
* '''In feature freeze:''' Initial state of a release branch. No features are added anymore. Bug-fixing mode. | * '''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 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. At this point we also go into [http://doc- | * '''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 [https://lists.qt-project.org/listinfo/localization Localization mailing] be informed about changes. At this point we also go into [http://doc-snapshots.qt.io/qtcreator-extending/coding-style.html#binary-and-source-compatibility soft API freeze]. | ||
* '''Freezing:''' Shortly before release candidate. Only P0/1 fixes (or high | * '''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 [http://doc-snapshots.qt.io/qtcreator-extending/coding-style.html#binary-and-source-compatibility 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. | * '''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. | ||
Latest revision as of 07:44, 10 December 2021
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.