Xfce Wiki

Sub domains
 

Differences

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

Link to this comparison view

releng:release-policy [2009/08/14 01:51]
jannis
releng:release-policy [2010/10/02 17:26]
Line 1: Line 1:
-====== Xfce Core Development and Release Model (DRAFT) ====== 
  
-Authors: 
-  * Jannis Pohlmann <​jannis@xfce.org>​ 
-  * Stephan Arts <​stephan@xfce.org>​ 
- 
-===== Introduction ===== 
- 
-In the past the same questions and discussions have come up over and over again whenever 
-a new release was in sight, like: 
- 
-  * What are the core components of Xfce? 
-  * How often do we want to release and in what fashion (time-based,​ feature-based)?​ 
-  * Who's in charge of the release process? 
-  * What dependency versions do we depend on? 
-  * When are feature-freeze,​ string-freeze,​ code-freeze and thelike? 
-  * How many pre-releases should we do and how do we call them? 
-  * What do we use as a replacement for SVN revision versioning with Git? 
- 
-This document intends to answer these questions and aims at defining a policy that we can  
-refer to when planning releases. 
- 
-===== The Xfce Core Desktop ===== 
- 
-==== Core Components ==== 
- 
-  * 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. 
- 
-==== Essential Dependencies ==== 
- 
-  * GTK+ 
-  * GLib 
-  * garcon 
-  * //TO BE DISCUSSED// 
- 
-===== The Release Cycle ===== 
- 
-The release cycle involves a short planning phase, a development phase with development releases ​ 
-and a release phase, eventually leading to a new stable release of the entire Xfce core desktop. 
-In parallel to these phases, a maintenance process of the current stable release will continue. ​ 
-During this phase, bugfix releases and security fixes will be released for the stable version 
-of Xfce. 
- 
-Below you can see a graphical timeline of an example release cycle and maintenance process for 
-Xfce 4.8 with three components: Thunar, exo and xfwm4. 
- 
-{{http://​lunar-linux.org/​~jannis/​xfce/​example-release-cycle.png|Example Release Cycle}} 
- 
-[[http://​lunar-linux.org/​~jannis/​xfce/​example-release-cycle.svg|SVG Source]] 
- 
-==== Planning Phase (2(+2) Weeks) ==== 
- 
-This phase marks the beginning of the release cycle and is used to decide which 
-dependencies to use and also to appoint the release team for the cycle (first 2 
-weeks). It eventually leads to the dependency freeze (after 4 weeks). 
- 
-=== Appointing the Release Team === 
- 
-At the beginning of the planning phase there is a (formal or informal) voting ​ 
-for the release team. The release team supervises development and maintenance ​ 
-releases during the release cycle. Its main purpose is to perform and double-check 
-the Xfce core desktop releases in the release phase at the very end 
-of the cycle. This is explained in more detail in the Release Team section of 
-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 === 
- 
-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 
-  - Investigate which dependencies are implied by that 
- 
-At the end of this, a decision is made on which dependencies the next  
-stable release of the Xfce core desktop will depend. In particular this  
-includes the minimum required versions for all essential dependencies of the  
-Xfce core desktop. 
- 
-Maintainers who were not available during the first 2 weeks of the planning 
-phase have the chance to request dependency changes in the 2 weeks after that.  
- 
-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. Optional 
-dependencies for are still allowed to be added though. 
- 
-=== Informing the Community === 
- 
-At the very end of the planning phase, a mail with planned features and  
-dependencies for all components of the Xfce core desktop is sent to the  
-xfce4-dev@xfce.org and xfce@xfce.org mailing lists. 
- 
-==== Development Phase (5 Months) ==== 
- 
-During the development phase every maintainer is free to do maintenance and development 
-releases of his components independently of the rest of Xfce.  
- 
-=== Development Releases === 
- 
-Development releases usually give a feature preview for the next stable release. ​ 
-They have to follow the X.Y.Z versioning format, where Y is an odd number (e.g.  
-xfwm4-4.7.3 or thunar-1.3.10). ​ 
- 
-Maintainers are encouraged to do development releases for new features they want  
-to make available to others. Frequent development releases can act as a replacement ​ 
-of the SVN revision versioning we had in the past. If component A depends on a  
-new feature in component B, A may only be released if there is a development ​ 
-release of B shipping this feature. For this to work, libtool versions have to  
-be updated properly with every development release. 
- 
-Care has to be taken of the master branch of each component. The master branch 
-should always remain in a release-ready state. New features should be developed 
-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 
-the risk of delaying the final release of the entire Xfce core desktop. ​ 
- 
-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.svg|SVG Source]] 
- 
-==== Release Phase (10+ Weeks) ==== 
- 
-During the release phase, there will be three pre-releases and one final release: 
- 
-  - Xfce X.Ypre1 (after ​ 0  weeks, feature freeze), 
-  - Xfce X.Ypre2 (after ​ 4  weeks, string freeze) and 
-  - Xfce X.Ypre3 (after ​ 8  weeks, code freeze) 
-  - Xfce X.Y     ​(after 10+ weeks) 
- 
-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 ​ 
-releases since the last stable release) of the Xfce core desktop. The version ​ 
-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 
-components along with one of the pre-releases. The release team always picks the  
-latest available development or stable release of each component for pre-releases ​ 
-and the final release. ​ 
- 
-The end of this phase marks a new stable release of the Xfce core desktop and  
-therewith the start of a new release cycle. 
- 
-=== Freezing before Releases === 
- 
-There are different freeze types before releases. ​ 
- 
-== Feature Freeze == 
- 
-With Xfce X.Ypre1, all core components enter feature freeze which means from there on 
-only translations and bugfixes are allowed to go into the master branch. 
- 
-== String/UI Freeze == 
- 
-With Xfce X.Ypre2, all core components enter string/UI freeze which means from there 
-on no strings which affect translations may be changed. Same goes for the user interface 
-which may not be changed after this point. 
- 
-== 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 
-no code changes are allowed, unless they are signed off by the release manager. These 
-should usually only be fixes to blocking or release-critical bugs. Translations are  
-still allowed to go in. 
- 
-=== Code Freeze Phase (2+ weeks) === 
- 
-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. 
- 
-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.svg|SVG Source]] 
- 
-== Bugfixes/​Changes == 
- 
-If a core component requires fixes or changes during code freeze, the maintainer 
-is required to create a new branch called ELS (//NAME OPEN FOR DISCUSSION//​) to which he 
-or she then commits the fixes. Refer to the section Code Freeze Exceptions if these  
-are release-critical changes or fixes for blocking bugs. 
- 
-The ELS branch only lives for a short period of time. It is merged into master and 
-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 == 
- 
-**Blocking Bugs** 
- 
-Certain bugs may delay the final release if they are considered blockers. This is 
-the case under any of the following circumstances:​ 
- 
-  * it crashes a core application ​ 
-  * it causes data loss  
-  * it causes an ever-growing memory leak 
-  * it locks the entire desktop GUI 
- 
-A bug may not delay a release if it meets the following criteria: 
- 
-  * the hardware or architecture on which the bug occurs is exotic and/or there'​s no way for developers to reproduce the bug 
- 
-Fixes for these bugs are allowed to be applied during code freeze if, and only if 
-they are signed off by the release manager. 
- 
-**Release-Critical Changes** 
- 
-Some changes may be of big concern with regards to the quality of the release. They 
-are allowed to go in if, and only if they are signed off by the release manager. 
- 
-== Releasing == 
- 
-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 ​ 
-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 
-or xfwm4-4.8. ​ 
- 
-==== Maintenance Process ==== 
- 
-After the release of a final version, bugfixes and translation updates will be committed to a stable ​ 
-component-specific branch (like thunar-1.2 or xfwm4-4.8). Maintenance releases of individual components 
-are not required to be synchronized. 
- 
-=== Maintenance Releases === 
- 
-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 
-number (e.g. xfwm4-4.8.4 or thunar-1.2.4). No new features or strings may be introduced in these 
-releases.