2 Release Scheduling In The Past

During the development and release of FreeBSD 5.X, many lessons were learned which only became clear in retrospect. The goals of the 5.X series were very aggressive, and included:

• To provide support for Symmetric MultiProcessing (SMP) machines;

• To increase performance by adopting a new strategy for dealing with resource contention in the kernel;

• To add several new processor architectures;

• To introduce a new threading model;

• To introduce a new scheduler;

• To add support for new technologies such as power management (especially important for laptops); and, most critically,

• Not to declare the release series as STABLE until all these tasks were finished.

This led to a situation where it was several years between the time that a release in the 4.X series was declared STABLE and that a release in the 5.X series was declared STABLE. This had several undesirable effects:

• The number of simultaneous feature-set changes made it very difficult to isolate one set of changes for merging back into the STABLE branch;

• which meant that users who absolutely had to have certain new features (for instance, to be able to run on modern hardware) wound up adopting (for instance) FreeBSD 5.2.1 even though it was advertised as a developer-only release, and regardless of the fact that a CURRENT release was not really suitable for their needs.

• In the cases where backmerges were made, this put the developers in a position of trying to support features on a version that they themselves were not using as their primary development platform.

• The time lag also meant that when 5.3 was finally declared as the latest STABLE release, the accumulated weight of changes made the upgrading process very painful.

To put it bluntly, no one was satisfied with this result.

The lessons that were learned are:

• New major releases must have a smaller number of feature-set changes and be released more often.

• To the maximum extent possible, feature-set changes should be isolated from each other. (This implies that some development must take place outside of the main tree and only be merged in when it will not destabilize other simultaneous development.)

• Major releases should be targeted at a time deadline rather than a feature-set deadline. If some feature is not ready in time, then it should be disabled by default and left for the next major release.

By releasing smaller sets of changes more often, it is also hoped that less time will be spent trying to merge features from HEAD back into the latest STABLE version (and thus trying to support those features in more than one major version); and further, that as the changes are more isolated, that the risk of introducing more bugs by doing so is much less.

Also, by focusing on a time deadline rather than a feature set, it should be finally be possible for users, developers of external applications, and the FreeBSD developers themselves to be able to better plan for the future.

These considerations, rather than any kind of keeping up with the major release number of any other OS, comprise the main motivation for the scheduling changes going forward.