There are the following types of qooxdoo releases:

• Patch Releases
• Minor Releases
• Major Releases

The following proposed scheme for qooxdoo release numbering uses ideas proposed by Semantic Versioning and the Django project:

• Versions are numbered in the form A.B or A.B.C.

• A is the major, B is the minor and C is the patch version number.
• In some cases, we’ll make alpha, beta, preview or candidate releases. These are of the form A.B-alpha/beta/pre/rcN, which means the Nth alpha/beta/release candidate of version A.B, e.g. 1.0-beta1.

Micro releases (1.0.1, 1.0.2, 1.1.1, etc.) contain bug and security fixes, and are supposed to be 100% compatible with the associated minor release. No migration steps are necessary when upgrading from any of the associated preceding releases. Projects should always upgrade to the latest patch release.

Minor release (1.1, 1.2, etc.) contain new features and improvements to existing features. Of course, they incorporate also fixes for bugs that were resolved during the regular development process. A minor release may deprecate certain features from previous releases. If a feature in version A.B is deprecated afterwards, it will continue to work in the next minor version version A.(B+1), but it will raise a DeprecationWarning. Typically version A.(B+2) will remove the feature entirely.

Major releases (2.0, etc.) will happen very infrequently (think “years”, not “months”). The changes that lead to such a major release are not necessarily backwards-compatible with the previous versions. That is, code you wrote for qooxdoo 1.0 may break when we release qooxdoo 2.0.

The following describes the proposed qooxdoo release scheduling. For a more accurate and constantly refined release planning, see the roadmap.

• Minor releases are expected about every 4 months.

• Major releases are not expected more often than every 1-2 years.

• Patch releases are decided upon on-demand.

• At the time of release of a minor version, a corresponding patch release of the previous minor branch will also be made available.
  Example: When releasing 1.1, another patch release within the 1.0.x branch appears, e.g. 1.0.2

• Final releases are available as tags\release_A_B_C

• After the release of a minor or major version development continues in trunk towards the next minor or major release.

• Patch releases are developed in a branches\branch_A_B_C, which leads towards a future A.B.C release.

• master/trunk should be as stable as reasonable
• Delete all branches not in use
• Only bugfixes in the release and patch branch
• Feature branches cannot begin with release
• Release branches are named as release-a.b.c
• There may be more than one feature branch
• A release branch only exists for several days (about 3 days)
• Feature branches may exist over a long time