Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
releng:release-policy [2009/05/28 14:56] – jannisreleng:release-policy [2009/08/14 01:51] – jannis
Line 25: Line 25:
 ==== Core Components ==== ==== Core Components ====
  
-//THE DEFINITION OF CORE COMPONENTS IS OPEN FOR DISCUSSION//+  * exo 
 +  * gtk-xfce-engine 
 +  * libxfce4ui 
 +  * libxfce4util 
 +  * thunar-vfs 
 +  * thunar 
 +  * xfce-utils 
 +  * xfce4-appfinder 
 +  * xfce4-panel 
 +  * xfce4-session 
 +  * xfce4-settings 
 +  * xfconf 
 +  * xfdesktop 
 +  * xfwm4
  
 All core components of the Xfce desktop have to adhere to the release policy defined in this document. All core components of the Xfce desktop have to adhere to the release policy defined in this document.
Line 93: Line 106:
   - Make sure API documentation is up to date   - Make sure API documentation is up to date
   - Create bugzilla tags   - Create bugzilla tags
 +  - Help the release manager
  
 **QA Official** **QA Official**
Line 159: Line 173:
 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 are+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 193:
 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 since the last stable release) of the Xfce core desktop. The version  
-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 or stable release of each component for pre-releases  
-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 the start of a new release cycle.
  
 === Freezing before Releases === === Freezing before Releases ===
  
-There are different types of freezing before releases. +There are different freeze types before releases. 
  
 == Feature Freeze == == Feature Freeze ==
Line 207: Line 222:
  
 == 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 235:
 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't allow any changes to master unless they are signed off
 +by the release manager. 
  
 {{http://lunar-linux.org/~jannis/xfce/code-freeze-branching.png|Tagging and Branching for Releases}} {{http://lunar-linux.org/~jannis/xfce/code-freeze-branching.png|Tagging and Branching for Releases}}
Line 225: Line 247:
  
 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//) to which he 
-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's stable branch (e.g. xfwm4-4.8 or thunar-1.2) after the final  
 +release. Only bugfixes are allowed in this branch. 
  
 == Code Freeze Exceptions == == Code Freeze Exceptions ==
Line 259: Line 282:
  
 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
Line 272: Line 295:
 === Maintenance Releases === === Maintenance Releases ===
  
-Maintenance releases have to be ABI and API compatible to the corresponding final release +There may be no API/ABI changes in maintenance releases compared to the corresponding final release 
 of the Xfce core desktop. They also have to follow the X.Y.Z versioning format, where Y is an even of the Xfce core desktop. They also have to follow the X.Y.Z versioning format, where Y is an even
 number (e.g. xfwm4-4.8.4 or thunar-1.2.4). No new features or strings may be introduced in these number (e.g. xfwm4-4.8.4 or thunar-1.2.4). No new features or strings may be introduced in these
 releases. releases.