Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
releng:release-policy [2009/05/28 11:00] – jannis | releng: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 < | + | |
- | * Stephan Arts < | + | |
- | + | ||
- | ===== 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, | + | |
- | * Who's in charge of the release process? | + | |
- | * What dependency versions do we depend on? | + | |
- | * When are feature-freeze, | + | |
- | * 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:// | + | |
- | + | ||
- | [[http:// | + | |
- | + | ||
- | ==== Planning Phase (1-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. | + | |
- | + | ||
- | 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. | + | |
- | + | ||
- | During this 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 phase, 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). | + | |
- | + | ||
- | After that, a mail with the dependencies and planned features 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 every completed new | + | |
- | feature and that 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** can 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:// | + | |
- | + | ||
- | [[http:// | + | |
- | + | ||
- | ==== Release Phase (10+ Weeks) ==== | + | |
- | + | ||
- | During the release phase, there will be three pre-releases and one final release: | + | |
- | + | ||
- | - Xfce X.Ypre1 (after | + | |
- | - Xfce X.Ypre2 (after | + | |
- | - Xfce X.Ypre3 (after | + | |
- | - Xfce X.Y | + | |
- | + | ||
- | 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 | + | |
- | 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. | + | |
- | + | ||
- | === Tagging and Branching for Releases === | + | |
- | + | ||
- | Starting with code freeze (Xfce X.Ypre3), all core components of the Xfce desktop | + | |
- | are branched. The new branch is called '' | + | |
- | lives for a short period of time. Only bugfixes are allowed in this branch. Starting | + | |
- | at this point until the final release, the master branch may only receive translation | + | |
- | updates. With 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 '' | + | |
- | master (where the development for the next release takes place) and into e.g. thunar-1.2 | + | |
- | or xfwm4-4.8. This is illustrated in the following figure: | + | |
- | + | ||
- | {{http:// | + | |
- | + | ||
- | [[http:// | + | |
- | + | ||
- | === 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' | + | |
- | + | ||
- | 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. | + | |
- | + | ||
- | === 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, | + | |
- | - 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 ==== | + | |
- | + | ||
- | 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. | + |