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 12:32] – 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 65: Line 78:
 of the cycle. This is explained in more detail in the Release Team section of of the cycle. This is explained in more detail in the Release Team section of
 this document. this document.
 +
 +== Release Team ==
 +
 +The release team consists of at least two people: one release manager who can
 +be assisted by others to actually perform the release (tagging, creation of 
 +tarballs, writing release notes and announcements) and another person for
 +quality assurance (checking if all components compile, tags are in place, 
 +release notes are up to date and so on). This is defined in more detail
 +below.
 +
 +These are the release team roles and their responsibilities:
 +
 +**Release Manager**
 +
 +  - Organization of the release cycle
 +  - Announce deadlines to developers and translators (repeatedly and early enough)
 +  - Overseeing of maintainance and development releases
 +  - Tagging of Xfce-X.Ypre1, Xfce-X.Y.pre2, Xfce-X.Y.pre3 and Xfce-X.Y
 +  - Generate tarballs from tags (possibly automated)
 +  - Write release notes
 +  - Write release announcements
 +  - Approve fixes of blocker bugs during code freeze
 +
 +**Release Assistant(s)**
 +
 +  - Update the website(s)
 +  - Make sure API documentation is up to date
 +  - Create bugzilla tags
 +  - Help the release manager
 +
 +**QA Official**
 +
 +  - Have an eye on libtool versions of maintanance and development releases
 +  - Remind maintainers about missing NEWS updates
 +  - Double-check the generated tarballs
 +  - Proof-read release announcements
 +
 +**Individual Maintainers**
 +
 +  - Create component-specific tags for their maintainance and development releases
 +  - Generate tarballs for their maintainance and development releases
 +  - Write ChangeLogs and update NEWS files
 +  - Write component-specific release announcements
  
 === Dependency Freeze === === Dependency Freeze ===
  
-During the planning phase (first 2 weeks) each maintainer is required to +During the first 2 weeks of the planning phase each maintainer is required to 
  
   - List the features he wants to implement in the release cycle   - List the features he wants to implement in the release cycle
Line 74: Line 130:
  
 At the end of this, a decision is made on which dependencies the next  At the end of this, a decision is made on which dependencies the next 
-stable release of the Xfce core desktop will depend on. In particular this +stable release of the Xfce core desktop will depend. In particular this 
 includes the minimum required versions for all essential dependencies of the  includes the minimum required versions for all essential dependencies of the 
-Xfce core desktop (mentioned above).+Xfce core desktop.
  
 Maintainers who were not available during the first 2 weeks of the planning Maintainers who were not available during the first 2 weeks of the planning
-phase have the chance to request dependency changes in the two weeks. After  +phase have the chance to request dependency changes in the 2 weeks after that. 
-that, features involving more recent dependency versions or even additional  +
-dependencies have to be made optional.+
  
 At the end of these 4 weeks, all components enter dependency freeze which means At the end of these 4 weeks, all components enter dependency freeze which means
-they may not change the dependencies (and their versions) they depend on.+they may not change the dependencies (and their versions) they depend on. Optional 
 +dependencies for are still allowed to be added though.
  
 === Informing the Community === === Informing the Community ===
Line 103: Line 158:
 xfwm4-4.7.3 or thunar-1.3.10).  xfwm4-4.7.3 or thunar-1.3.10). 
  
-Maintainers are encouraged to do a new development release for every completed new +Maintainers are encouraged to do development releases for new features they want  
-feature and that they want to make available to others. Frequent development releases +to make available to others. Frequent development releases can act as a replacement  
-can act as a replacement of the SVN revision versioning we had in the past. If component +of the SVN revision versioning we had in the past. If component A depends on a  
-**A** depends on a new feature in component **B**, **A** can only be released if there is +new feature in component B, A may only be released if there is a development  
-a development release of **B** shipping this feature. For this to work, libtool +release of B shipping this feature. For this to work, libtool versions have to  
-versions have to be updated properly with every development release.+be updated properly with every development release.
  
 Care has to be taken of the master branch of each component. The master branch Care has to be taken of the master branch of each component. The master branch
Line 114: Line 169:
 in branches until they are ready (as in: compiling and the component will remain in branches until they are ready (as in: compiling and the component will remain
 functional even after merging the feature(s) into the master branch), to lower functional even after merging the feature(s) into the master branch), to lower
-the risk of delaying the final release of the entire Xfce core desktop. This is +the risk of delaying the final release of the entire Xfce core desktop.  
-how the basic development workflow looks like:+ 
 +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  
 +before including the features in a new development release. That way the other components 
 +retain their release-ready state. 
 + 
 +This is how the basic development workflow looks like:
  
 {{http://lunar-linux.org/~jannis/xfce/feature-branching.png|Development Workflow}} {{http://lunar-linux.org/~jannis/xfce/feature-branching.png|Development Workflow}}
Line 131: Line 192:
  
 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 of the Xfce core desktop. The version numbers  +development releases of all components (or stable, if there were no development  
-of these components may (even have to) differ from the naming scheme above. E.g. for +releases since the last stable release) of the Xfce core desktop. The version  
-Xfce 4.8.0pre2, xfwm4 could have the version 4.7.17 and Thunar could have 1.1.9. +numbers of these components may (even have to) differ from the naming scheme above.  
 +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 159: 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 169: 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 177: 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 211: 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
 or xfwm4-4.8.  or xfwm4-4.8. 
- 
-=== Release Team === 
- 
-The release team consists of at least two people: one release manager who can 
-be assisted by others to actually perform the release (tagging, creation of  
-tarballs, writing release notes and announcements) and another person for 
-quality assurance (checking if all components compile, tags are in place,  
-release notes are up to date and so on). This is defined in more detail 
-below. 
- 
-These are the release team roles and their responsibilities: 
- 
-== Release Manager == 
- 
-  - Organization of the release cycle 
-  - Announce deadlines to developers and translators (repeatedly and early enough) 
-  - Overseeing of maintainance and development releases 
-  - Tagging of Xfce-X.Ypre1, Xfce-X.Y.pre2, Xfce-X.Y.pre3 and Xfce-X.Y 
-  - Generate tarballs from tags (possibly automated) 
-  - Write release notes 
-  - Write release announcements 
-  - Approve fixes of blocker bugs during code freeze 
- 
-== Release Assistant(s) == 
- 
-  - Update the website(s) 
-  - Make sure API documentation is up to date 
-  - Create bugzilla tags 
- 
-== QA Official == 
- 
-  - Have an eye on libtool versions of maintanance and development releases 
-  - Remind maintainers about missing NEWS updates 
-  - Double-check the generated tarballs 
-  - Proof-read release announcements 
- 
-== Individual Maintainers == 
- 
-  - Create component-specific tags for their maintainance and development releases 
-  - Generate tarballs for their maintainance and development releases 
-  - Write ChangeLogs and update NEWS files 
-  - Write component-specific release announcements 
  
 ==== Maintenance Process ==== ==== Maintenance Process ====
Line 266: 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.