Login | Register
My pages Projects Community openCollabNet
Project highlights:

29 Sep 2014: Release 2.3.4 is now available at the download page.

24 Aug 2014: Release 2.3.3 is now available at the download page.

05 July 2014: Release 2.3.2 is now available at the download page.

02 Feb 2013: Release 2.3.0 is now available at the download page.

Release Roadmap

Current Releases

The current stable release is 2.3.4, released 29 Sep 2014.

Upcoming Releases

Our goal is to meet the dates for release candidates and the releases themselves; the beta checkpoint dates are our best guess as this was published, but they may be adjusted without notice.

Estimated date Type Comments
Oct 2012 2.3 New features

Release Planning

Release numbering

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

  • 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 release of the same major version with complete confidence that your build will not break. We expect that our major releases will be long-lived platforms with many minor releases to add functionality and fix bugs.

  • Minor release (1.1, 1.2, 1.3, etc.)

    Minor numbers increment for releases that add new functionality and/or bug fixes to an existing major release. Any new functionality will never knowingly break backwards compatibility with any previous minor releases from the same major release.

  • Bug-fix revisions (1.0.1, 1.1.1, 1.2.1, etc.)

    Revision numbers are appended and/or incremented whenever a critical bug fix is necessary for a major or minor release. Because most new functionality and bug fixes will be delivered in minor releases, we expect that there will be few of these—at most one per minor release.

  • Release candidates (x.y.z.dyyyymmdd)

    A release candidates is a special form of checkpoint (see below) that is expected to be the next major or minor release. If blocking issues show up in the candidate, another candidate will normally be issued (potentially delaying the release date), otherwise the candidate will be repackaged as the major or minor release.

  • Checkpoints (x.y.z.dyyyymmdd)

    A checkpoint has a 'dyyymmdd' suffix and is made every couple of weeks between major or minor releases. It is intended for beta testing new features and for ensuring that bug fixes work as intended. Although existing features from the previous release will not change, compatibility of features under test is not guaranteed between checkpoints (i.e., the implementation of the feature may change). Checkpoints are intended not only to allow for wider testing, but also to make new features available to users (who may urgently need one of them) in advance of them being published in the next major or minor release.