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
releng:release-policy [2009/08/14 01:51] – jannisreleng:release-policy [2010/10/02 17:26] (current) – external edit 127.0.0.1
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 ==== +
- +
-  * 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.+