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 12:31] – jannis | releng:release-policy [2009/05/28 12:44] – jannis | ||
---|---|---|---|
Line 55: | Line 55: | ||
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 (first 2 | dependencies to use and also to appoint the release team for the cycle (first 2 | ||
- | weeks). It eventually leads to the dependency freeze (after | + | weeks). It eventually leads to the dependency freeze (after 4 weeks). |
=== Appointing the Release Team === | === Appointing the Release Team === | ||
Line 65: | Line 65: | ||
of the cycle. This is explained in more detail in the Release Team section of | of the cycle. This is explained in more detail in the Release Team section of | ||
this document. | 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, | ||
+ | - 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 === | === Dependency Freeze === | ||
- | During the planning phase (first 2 weeks) each maintainer is required to | + | 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 | - List the features he wants to implement in the release cycle | ||
Line 79: | Line 121: | ||
Maintainers who were not available during the first 2 weeks of the planning | Maintainers who were not available during the first 2 weeks of the planning | ||
- | phase have the chance to request dependency changes in the two weeks. After | + | phase have the chance to request dependency changes in the 2 weeks after that. |
- | that, features involving more recent dependency versions or even additional | + | |
- | dependencies have to be made optional. | + | |
At the end of these 4 weeks, all components enter dependency freeze which means | 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. | + | 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 === | === Informing the Community === | ||
Line 103: | Line 144: | ||
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 release for every completed | + | Maintainers are encouraged to do a new development release for new features |
- | 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 131: | Line 172: | ||
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 numbers | + | development releases of all components |
- | of these components may (even have to) differ from the naming scheme above. E.g. for | + | releases) |
- | Xfce 4.8.0pre2, xfwm4 could have the version 4.7.17 and Thunar could have 1.1.9. | + | 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 | This means that maintainers don't necessarily have to release new versions of their | ||
Line 212: | Line 254: | ||
For the final release (Xfce X.Y), all core components are tagged (twice, once | 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 | 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 '' | + | 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 | master (where the development for the next release takes place) and into e.g. thunar-1.2 | ||
or xfwm4-4.8. | or xfwm4-4.8. | ||
- | |||
- | === 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 ==== | ==== Maintenance Process ==== |