|
|
Disclaimer: This page blatantly took content from Ubuntu [Stable Release Policy](https://wiki.ubuntu.com/StableReleaseUpdates).
|
|
|
|
|
|
Once a BIND 9 release has been completed, published and designated as ESV, updates for it are only released under certain circumstances, and must follow a special procedure called a "stable release update" or SRU.
|
|
|
|
|
|
# Why
|
|
|
|
|
|
In contrast to pre-release versions and stable versions, official ESV releases of BIND 9 are subject to much wider use, and by a different demographic of users. During development, changes to the distribution primarily affect developers, early adopters, and other advanced users, all of whom have elected to use pre-release software at their own risk.
|
|
|
|
|
|
Users of the official release, in contrast, expect a high degree of stability. They use their BIND 9 for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with BIND9 and expect a reliable server that does not require their intervention.
|
|
|
|
|
|
Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution. Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.
|
|
|
|
|
|
_"It's just a one-line change!"_
|
|
|
|
|
|
Even the simplest of changes can cause unexpected regressions due to lurking problems:
|
|
|
|
|
|
* In bug XXXXX, the journal file got broken.
|
|
|
* In bug YYYYY, the masterfile map format was deemed incompatible.
|
|
|
* In bug ZZZZZ, ... are more examples needed?
|
|
|
|
|
|
We never assume that any change, no matter how obvious, is completely free of regression risk.
|
|
|
|
|
|
[REWRITE] In line with this, the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable server possible, and this often involves fundamental improvements to the system's architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimize risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimizing the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases.
|
|
|
|
|
|
# When
|
|
|
|
|
|
## High-impact bugs
|
|
|
|
|
|
Stable release updates will, in general, only be issued in order to fix **high-impact bugs**. Examples of such bugs include:
|
|
|
|
|
|
* Bugs which may, under realistic circumstances, directly cause a security vulnerability. These are done by the security team and are documented at ????.
|
|
|
* Bugs which represent severe regressions from the previous release of Ubuntu. This includes packages which are totally unusable, like being uninstallable or crashing on startup.
|
|
|
* Bugs which may, under realistic circumstances, directly cause a loss of user data
|
|
|
* Updates that need to be applied to BIND 9 to adjust to changes in the environment, server protocols, web services, and similar, i. e. where the current version just ceases to work. Examples:
|
|
|
* New RRTYPES preferrably without additional processing
|
|
|
* New EDNS0 options
|
|
|
* ????
|
|
|
|
|
|
## Other safe cases
|
|
|
|
|
|
In the following cases a stable release update is also applicable as they have a low potential for regressing existing installations but a high potential for improving the user experience, particularly for Extended Support releases:
|
|
|
|
|
|
* Bugs requested by customers. These are done by the support team and documented at ????.
|
|
|
* **FTBFS**(Fails To Build From Source) for supported platforms can also be considered.
|
|
|
|
|
|
# Procedure
|
|
|
|
|
|
[NEEDS REWRITE FOR BIND 9]
|
|
|
|
|
|
1. Check that the bug is fixed in the current development release and that its bug task is "Fix Released". Equivalently for new upstream releases, this (or a newer) release must be in the development release. It is, in general, not appropriate to release updates for stable systems without first testing them in the current development branch. One exception to this general rule is the case where the development release is not yet open, there can sometimes be a delay between the release of the most recent version of Ubuntu and the opening for the development of the next version. Provided they are important enough, stable release updates should not and do not need to wait for the development release to open.
|
|
|
|
|
|
2. Ensure that the bug report for this issue is public.
|
|
|
|
|
|
3. ?????
|
|
|
|
|
|
4. Any bug fix that is backported to the ESV release must be accompanied by a system test and preferably also a unit test.
|
|
|
|
|
|
# Documentation for Special Cases |