Release Plan Details
We are more conservative in our package merge with Debian, auto-synching with Debian testing, instead of Debian unstable.
- We start stabilizing the release early by significantly limiting the number of new features. We will choose which features we package into the LTS release, versus which ones we leave out and allow for users to optionally download and use from a separate archive.
Avoid structural changes as far as possible, such as changing the default set of applications, lots of library transitions, or system layer changes (example: introducing KMS or hal → DeviceKit would not have been appropriate changes in a LTS).
Furthermore, we define the LTS to be:
Enterprise Focused: We are targeting server and multiple desktop installations, where the average user is moderately risk averse.
Compatible with New Hardware: We will make point releases throughout the development cycle to provide functional support for new server and desktop hardware.
More Tested: We will shorten the development window and extend the Beta cycle to allow for more testing and bug fixing
and clearly state that it is not:
A Feature-Based Release: We will focus on hardening functionality of existing features, versus introducing new ones1, except for in the areas of Online Services and Desktop Experience2.
1. Exceptions for priority projects will be documented, with Feature Freeze coinciding with the Beta1 Freeze date
2. Because these two areas of development are relatively new, they still require new features to satisfy the original reasons for their creationCutting Edge: Instead of doing an automatic full package import from Debian unstable, we will do it from Debian testing1. The benefit we gain from not introducing new bugs and/or regressions outweighs the new features and/or fixes we often get from unstable.
1. We reserve the right to selectively pull in updates from unstable, if we believe the stability of the package in Debian is better than what is in the current Ubuntu archive.
To support our goal of ensuring stability, we plan to make a small number of changes to the release schedule:
Reduced Alpha Stage: Because we will have substantially less new code, we can reduce the number of Alpha releases, and extend the Beta stage to allow for more system testing.
Two Beta Releases: We generally get more bugs filed in the Beta stage because of the increase in user base. In order to address more of these issues, we will provide an additional Beta release.