Qt Creator Submission Policies: Difference between revisions

From Qt Wiki
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 ‘regular’ Qt Creator development (e.g. '''wip/clang''')
* '''Master branch:''' Branch where new features and other 'major' things are pushed (i.e. '''master''')
* '''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''')
* '''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.<br /> The minor version branch is regularly merged up to Master.
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&amp;merge after it is finished, can include but is not limited to
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 (<span class="caps">CLA</span> requires submission of individual commits to gerrit for each contributor)
* 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 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).
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-snapshot.qt.io/qtcreator-extending/coding-style.html#binary-and-source-compatibility soft <span class="caps">API</span> freeze] ''[doc-snapshot.qt.io]''.
* '''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 “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-snapshot.qt.io/qtcreator-extending/coding-style.html#binary-and-source-compatibility hard <span class="caps">API</span> freeze] ''[doc-snapshot.qt.io]''.
* '''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.
The '''Freezing''' state starts shortly before the release candidate, and continues through the final minor.0 release, and a potential patch release. After that, the branch is put into '''Frozen''' mode. It can be defrosted by the Qt Creator maintainer if need arises, but that would be only in exceptional circumstances. After all, Qt Creator’s release cycle is tight and the next minor release not far away.
===Categories:===
* [[:Category:Tools|Tools]]
** [[:Category:Tools::QtCreator|QtCreator]]

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.