Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
releng:release-policy [2009/05/28 14:56] – jannis | releng:release-policy [2009/05/28 17:00] – jannis | ||
---|---|---|---|
Line 159: | Line 159: | ||
New features breaking APIs or other core components should be communicated. Maintainers | New features breaking APIs or other core components should be communicated. Maintainers | ||
are suggested to prepare other components for these features in a separate branch | are suggested to prepare other components for these features in a separate branch | ||
- | before including the features in a new development release. That way components | + | before including the features in a new development release. That way the other components |
retain their release-ready state. | retain their release-ready state. | ||
Line 179: | Line 179: | ||
where Y has to be an even number. Each of these releases has to include the latest | where Y has to be an even number. Each of these releases has to include the latest | ||
development releases of all components (or stable, if there were no development | development releases of all components (or stable, if there were no development | ||
- | releases) of the Xfce core desktop. The version numbers of these components may (even | + | releases |
- | have to) differ from the naming scheme above. E.g. for Xfce 4.8.0pre2, xfwm4 could | + | numbers of these components may (even have to) differ from the naming scheme above. |
- | have the version 4.7.17 and Thunar could have 1.1.9. | + | E.g. for Xfce 4.8.0pre2, xfwm4 could have the version 4.7.17 and Thunar could |
+ | have 1.1.9. | ||
This means that maintainers don't necessarily have to release new versions of their | This means that maintainers don't necessarily have to release new versions of their | ||
components along with one of the pre-releases. The release team always picks the | components along with one of the pre-releases. The release team always picks the | ||
- | latest available development release of each component for pre-releases and the | + | latest available development |
- | final release. | + | and the final release. |
- | The end of this phase marks a new stable release of the Xfce core desktop and therewith | + | The end of this phase marks a new stable release of the Xfce core desktop and |
- | the start of a new release cycle. | + | therewith |
=== Freezing before Releases === | === Freezing before Releases === | ||
- | There are different types of freezing | + | There are different |
== Feature Freeze == | == Feature Freeze == | ||
Line 207: | Line 208: | ||
== Code Freeze == | == Code Freeze == | ||
+ | |||
+ | There is a short 2-days code freeze before every pre-release. During this period of time, | ||
+ | no commits may be sent unless they are signed off by the release manager. | ||
With Xfce X.Ypre3, all core components enter code freeze which means from there on | With Xfce X.Ypre3, all core components enter code freeze which means from there on | ||
Line 217: | Line 221: | ||
With Xfce X.Ypre3, all core components enter code freeze. This phase is illustrated | With Xfce X.Ypre3, all core components enter code freeze. This phase is illustrated | ||
in the following figure and is explained in more detail in this section. | in the following figure and is explained in more detail in this section. | ||
+ | |||
+ | The code freeze and its exceptions are supported by commit hooks. There is an | ||
+ | update hook which doesn' | ||
+ | by the release manager. | ||
{{http:// | {{http:// | ||
Line 225: | Line 233: | ||
If a core component requires fixes or changes during code freeze, the maintainer | If a core component requires fixes or changes during code freeze, the maintainer | ||
- | is required to create a new branch called ELS to which he or she then commits the fixes. | + | is required to create a new branch called ELS (//NAME OPEN FOR DISCUSSION// |
- | Refer to the section Code Freeze Exceptions if these are release-critical changes or | + | or she then commits the fixes. Refer to the section Code Freeze Exceptions if these |
- | fixes for blocking bugs. | + | are release-critical changes or fixes for blocking bugs. |
- | The ELS branch only lives for a short period of time. Only bugfixes are allowed in | + | The ELS branch only lives for a short period of time. It is merged into master and |
- | this branch. | + | into the component' |
+ | release. Only bugfixes are allowed in this branch. | ||
== Code Freeze Exceptions == | == Code Freeze Exceptions == | ||
Line 259: | Line 268: | ||
For the final release (Xfce X.Y), all core components are tagged (twice, once | For the final release (Xfce X.Y), all core components are tagged (twice, once | ||
- | with their own version and once with xfce-x.y.0) and branched for the maintenance | + | with their own version and once with xfce-X.Y.0) and branched for the maintenance |
cycle (e.g. as thunar-1.2 or xfwm4-4.8). After that, the ELS branch is merged into | cycle (e.g. as thunar-1.2 or xfwm4-4.8). After that, the ELS branch is merged into | ||
master (where the development for the next release takes place) and into e.g. thunar-1.2 | master (where the development for the next release takes place) and into e.g. thunar-1.2 |