initCommon(); $template->displayHeader(); ?>

Chapter 2. Package Versions

The following rules apply:

  1. Stable releases are allowed until the feature freeze date.

  2. Stable snapshots are generally OK, but there has to be a good reason why you want to use the stable snapshot instead of the stable release plus patches. This is generally more acceptable for larger, well-maintained projects such as gcc, gdb).

  3. Alpha releases are usually not OK. Obviously, there are some packages whose upstream maintainers have never changed their versions from -alpha. Basically, this guideline applies when there is a previous stable version available.

  4. Beta releases are generally not OK. Refer to Section 2.1, “Beta Exceptions”.

  5. Development/beta snapshots are generally not OK.

2.1. Beta Exceptions

For large important packages with a maintained developer base, shipping beta/pre-release versions is OK during a development cycle, provided all of the following are met:

  • The upstream maintainer does not mind

  • The package has entered a pre-release/stabilization/release-candidate phase

  • The package's release dates are known to be before any relevant freezes

This is mainly important for things that do not have many beta releases, such as XFree86, KDE, and so on.

Also, if it is something fundamentally required for development of certain features, it is OK, provided the final version will be available by the time we freeze.

In general, if it is on http://alpha.gnu.org/, it is probably a bad idea.

Remember these are guidelines. Use good judgment. The idea is to offer new things to our users not just because they are newer, but because they provide either feature enhancements or better stability (bug fixes).

displayFooter('$Date: 2005/12/06 19:37:03 $'); ?>