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
Last revisionBoth sides next revision
releng:release-policy [2009/05/28 12:44] jannisreleng:release-policy [2009/08/16 18:04] jannis
Line 1: Line 1:
-====== Xfce Core Development and Release Model (DRAFT) ====== +This page [[release-model|has moved]].
- +
-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 ==== +
- +
-//THE DEFINITION OF CORE COMPONENTS IS OPEN FOR DISCUSSION// +
- +
-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 +
- +
-**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 on. In particular this  +
-includes the minimum required versions for all essential dependencies of the  +
-Xfce core desktop (mentioned above). +
- +
-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 a new development release 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. 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) 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 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 types of freezing 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 == +
- +
-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. +
- +
-{{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 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. 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 === +
- +
-Maintenance releases have to be ABI and API compatible 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.+