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 14:50] – jannis | releng:release-policy [2009/05/28 14:59] – jannis | ||
---|---|---|---|
Line 118: | Line 118: | ||
stable release of the Xfce core desktop will depend. In particular this | 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 | + | Xfce core desktop. |
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 | ||
Line 144: | 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 | + | Maintainers are encouraged to do development |
to make available to others. Frequent development releases can act as a replacement | 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 | of the SVN revision versioning we had in the past. If component A depends on a | ||
Line 155: | Line 155: | ||
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 173: | Line 179: | ||
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 (or stable, if there were no development | development releases of all components (or stable, if there were no development | ||
- | releases) of the Xfce core desktop. The version numbers of these components may (even | + | releases |
- | have to) differ from the naming scheme above. E.g. for Xfce 4.8.0pre2, xfwm4 could | + | numbers of these components may (even have to) differ from the naming scheme above. |
- | have the version 4.7.17 and Thunar could have 1.1.9. | + | 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 |