include("site.inc"); $template = new Page; $template->initCommon(); $template->displayHeader(); ?>
The following rules apply:
Stable releases are allowed until the feature freeze date.
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
).
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.
Beta releases are generally not OK. Refer to Section 2.1, “Beta Exceptions”.
Development/beta snapshots are generally not OK.
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).