Current Releases

The current stable release is 0.96.1, released 23 August 2004.

The current testing pre-release is 0.96.92, released 10 April 2006.

(Yes, the current "stable" release is a little long in the tooth. In practice, most everyone uses the testing pre-releases, because our testing methodology gives us a pretty good track record of not breaking things from release to release.)

Upcoming Releases

Take these with a huge grain of salt, this is very rough planning and subject to change.

Release	Est. Date?	Goals
0.96.93	???	Significant speed up of some specific configurations, plus accumulated patches with bug fixes and new functionality. Fix for the one regression found so far in 0.96.92 (printing an incorrect message when executing the InstallAs() function).
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 just SConscript) files. Hooks for supporting tool-generated dependency information (like gcc -M) 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. The following features have been suggested as prerequisites for a fully-feature 1.0 release: C/C++ dependency scanning that acts like a real C preprocessor (computed file names, #ifdef analysis)
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 release (1.1.1, 1.1.2, 1.1.3, etc.)

  Sub-release numbers are used whenever a critical bug fix is necessary for a major or minor release.

• Testing pre-release (1.1.90, 1.1.91, 1.1.92, 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. There may be many of these leading up to a release with a lot of significant internal changes (*cough* 0.97 *cough*...).