Differences
This shows you the differences between two versions of the page.
|
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. | ||