Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
releng:release-policy [2009/05/28 11:00] – jannis | releng:release-policy [2009/08/14 01:41] – jannis | ||
---|---|---|---|
Line 25: | Line 25: | ||
==== Core Components ==== | ==== Core Components ==== | ||
- | //THE DEFINITION OF CORE COMPONENTS IS OPEN FOR DISCUSSION// | + | * 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. | All core components of the Xfce desktop have to adhere to the release policy defined in this document. | ||
Line 51: | Line 64: | ||
[[http:// | [[http:// | ||
- | ==== Planning Phase (1-2 Weeks) ==== | + | ==== Planning Phase (2(+2) Weeks) ==== |
This phase marks the beginning of the release cycle and is used to decide which | 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. | + | 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 | At the beginning of the planning phase there is a (formal or informal) voting | ||
Line 63: | Line 79: | ||
this document. | this document. | ||
- | During | + | == 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 | ||
+ | |||
+ | === Dependency Freeze === | ||
+ | |||
+ | During | ||
- List the features he wants to implement in the release cycle | - List the features he wants to implement in the release cycle | ||
- Investigate which dependencies are implied by that | - Investigate which dependencies are implied by that | ||
- | At the end of this phase, a decision is made on which dependencies the next | + | At the end of this, a decision is made on which dependencies the next |
- | stable release of the Xfce core desktop will depend | + | stable release of the Xfce core desktop will depend. In particular this |
includes the minimum required versions for all essential dependencies of the | includes the minimum required versions for all essential dependencies of the | ||
- | Xfce core desktop (mentioned above). | + | 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 | ||
+ | dependencies for are still allowed to be added though. | ||
+ | |||
+ | === Informing the Community === | ||
- | After that, a mail with the dependencies and planned features for all components | + | At the very end of the planning phase, a mail with planned features |
- | of the Xfce core desktop is sent to the xfce4-dev@xfce.org and xfce@xfce.org | + | dependencies |
- | mailing lists. | + | xfce4-dev@xfce.org and xfce@xfce.org mailing lists. |
==== Development Phase (5 Months) ==== | ==== Development Phase (5 Months) ==== | ||
Line 88: | Line 157: | ||
xfwm4-4.7.3 or thunar-1.3.10). | xfwm4-4.7.3 or thunar-1.3.10). | ||
- | Maintainers are encouraged to do a new development | + | Maintainers are encouraged to do development |
- | feature and that they want to make available to others. Frequent development releases | + | to make available to others. Frequent development releases can act as a replacement |
- | can act as a replacement of the SVN revision versioning we had in the past. If component | + | of the SVN revision versioning we had in the past. If component A depends on a |
- | **A** depends on a new feature in component | + | new feature in component B, A may only be released if there is a development |
- | a development release of **B** shipping this feature. For this to work, libtool | + | release of B shipping this feature. For this to work, libtool versions have to |
- | versions have to be updated properly with every development release. | + | be updated properly with every development release. |
Care has to be taken of the master branch of each component. The master branch | Care has to be taken of the master branch of each component. The master branch | ||
Line 99: | Line 168: | ||
in branches until they are ready (as in: compiling and the component will remain | 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 | 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 | + | the risk of delaying the final release of the entire Xfce core desktop. |
- | how the basic development workflow looks like: | + | |
+ | 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:// | {{http:// | ||
Line 116: | Line 191: | ||
where Y has to be an even number. Each of these releases has to include the latest | 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 | + | development releases of all components |
- | of these components may (even have to) differ from the naming scheme above. E.g. for | + | releases since the last stable release) |
- | Xfce 4.8.0pre2, xfwm4 could have the version 4.7.17 and Thunar could have 1.1.9. | + | numbers |
+ | 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 | 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 | 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 | + | latest available development |
- | final release. | + | and the final release. |
- | The end of this phase marks a new stable release of the Xfce core desktop and therewith | + | The end of this phase marks a new stable release of the Xfce core desktop and |
- | the start of a new release cycle. | + | therewith |
=== Freezing before Releases === | === Freezing before Releases === | ||
- | There are different types of freezing | + | There are different |
== Feature Freeze == | == Feature Freeze == | ||
Line 144: | Line 221: | ||
== Code Freeze == | == 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 | With Xfce X.Ypre3, all core components enter code freeze which means from there on | ||
Line 150: | Line 230: | ||
still allowed to go in. | still allowed to go in. | ||
- | === Tagging and Branching for Releases | + | === Code Freeze Phase (2+ weeks) |
- | Starting with code freeze (Xfce X.Ypre3), all core components | + | With Xfce X.Ypre3, all core components |
- | are branched. The new branch | + | in the following figure and is explained in more detail |
- | lives for a short period of time. Only bugfixes are allowed | + | |
- | at this point until the final release, the master branch may only receive translation | + | The code freeze and its exceptions |
- | updates. With the final release (Xfce X.Y), all core components | + | update hook which doesn't allow any changes to master unless they are signed off |
- | with their own version and once with xfce-x.y.0) and branched for the maintenance | + | by the release |
- | cycle (e.g. as thunar-1.2 or xfwm4-4.8). After that, the '' | + | |
- | master (where | + | |
- | or xfwm4-4.8. This is illustrated in the following figure: | + | |
{{http:// | {{http:// | ||
Line 166: | Line 243: | ||
[[http:// | [[http:// | ||
- | === Code Freeze Exceptions === | + | == Bugfixes/ |
+ | |||
+ | 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// | ||
+ | or she then commits the fixes. Refer to the section | ||
+ | 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' | ||
+ | release. Only bugfixes are allowed in this branch. | ||
+ | |||
+ | == Code Freeze Exceptions | ||
- | == Blocking Bugs == | + | **Blocking Bugs** |
Certain bugs may delay the final release if they are considered blockers. This is | Certain bugs may delay the final release if they are considered blockers. This is | ||
Line 185: | Line 273: | ||
they are signed off by the release manager. | they are signed off by the release manager. | ||
- | == Release-Critical Changes | + | **Release-Critical Changes** |
Some changes may be of big concern with regards to the quality of the release. They | 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. | are allowed to go in if, and only if they are signed off by the release manager. | ||
- | === Release Team === | + | == Releasing |
- | The release team consists of at least two people: one release manager who can | + | For the final release (Xfce X.Y), all core components are tagged (twice, once |
- | be assisted by others to actually perform | + | with their own version |
- | tarballs, writing release notes and announcements) and another person for | + | cycle (e.g. as thunar-1.2 or xfwm4-4.8). After that, the ELS branch is merged into |
- | quality assurance (checking if all components | + | master |
- | release notes are up to date and so on). This is defined in more detail | + | or xfwm4-4.8. |
- | below. | + | |
- | + | ||
- | These are the release team roles and their responsibilities: | + | |
- | + | ||
- | == Release Manager == | + | |
- | + | ||
- | - Organization of the release | + | |
- | - Announce deadlines to developers and translators | + | |
- | - 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 | + | |
- | - Make sure API documentation is up to date | + | |
- | - Create bugzilla tags | + | |
- | + | ||
- | == QA Official == | + | |
- | + | ||
- | - Have an eye on libtool versions of maintanance and development | + | |
- | - Remind maintainers about missing NEWS updates | + | |
- | - Double-check | + | |
- | - Proof-read | + | |
- | + | ||
- | == Individual Maintainers == | + | |
- | + | ||
- | - Create component-specific tags for their maintainance | + | |
- | | + | |
- | - Write ChangeLogs and update NEWS files | + | |
- | - Write component-specific release announcements | + | |
==== Maintenance Process ==== | ==== Maintenance Process ==== | ||
Line 240: | Line 294: | ||
=== Maintenance Releases === | === Maintenance Releases === | ||
- | Maintenance releases have to be ABI and API compatible | + | There may be no API/ABI changes in maintenance releases compared |
of the Xfce core desktop. They also have to follow the X.Y.Z versioning format, where Y is an even | 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 | number (e.g. xfwm4-4.8.4 or thunar-1.2.4). No new features or strings may be introduced in these | ||
releases. | releases. |