Current Releases

The current "stable" release is 0.96.1.

The current testing pre-release is 0.96.92.

Upcoming Releases

Take these with a huge grain of salt, this is very rough planning.

Release	Est. Date (yeah, right)	Goals
0.96.93	???	Significant speed up of some specific configurations, plus accumulated patches. Fix for the one cosmetic bug found so far in 0.96.92.
0.96.94	???	Testing pre-release of the "Big Signature Refactoring," a significant re-design of internal data structures to accomplish the following: Interoperability between MD5 signatures and timestamps. Ability to partition the dependency graph into separate SConstruct (not SConscript) files. Improved performance (we hope)
0.97	???	Wider release and more extensive field testing before declaring the "Big Signature Refactoring" ready to be blessed as the official 1.0 release. Additional features and bug fixes.
1.0	???	First official, stable release. No 1.x release will (knowingly) break compatibility or cause a rebuild on upgrade.
2.0	???	First release that will break backwards compatibility with Python 1.5.2.

Release Planning

Why has 1.0 still not been released?

As seems so common these days, SCons has had an extremely lengthy "beta" period. The primary goal has been to arrive at something by 1.0 that we feel is absolutely rock-solid-stable and which people can download and use without fear of broken builds or unnecessary rebuilds. To get some idea of how we do this, see our testing philosophy page.

Release numbering

Our release numbers are of the form major.minor.sub.

Major release (1.0, 2.0, 3.0, etc.)
The major number increments when one of two things happens:
- The release knowingly breaks backwards compatibility in some way.
- The release knowingly causes a rebuild when you upgrade.
Our goal is that as a user of SCons, you should always be able to upgrade to a later revision of the same major number with complete confidence that your build will not break.
Minor release (1.1, 1.2, 1.3, etc.)
Minor releases will add new functionality to an existing major release branch. All new functionality will be added so as to never knowingly break backwards compatibility with any previous minor releases from the same branch. We expect that our major release branches will be long-lived platforms for delivering many minor releases to add functionality.
Bug-fix sub-release (1.1.1, 1.1.2, 1.1.3, etc.)
Released whenever a critical bug fix is necessary for a major or minor release.
Testing pre-release (1.1.90, 1.1.91, 1.1.93, etc.)
A sub-release number of 90 or greater indicates the release is intended for testing a set of new features intended for wider distribution in the next major or minor release.

Our release numbers are of the form major.minor.sub.