<html> <head> <title>scons: Release Roadmap</title> </head> <body> <div id="apphead"> <h1><small>Release Roadmap</small></h1> </div> <div class="h2 app" style="border-left: 0px" id="customcontent"> <h2>Current Releases</h2> <p> The current stable release is 1.0.1, released 12 August 2008. </p> <p> The latest release is 1.0.1, released 7 September 2008. </p> <h2>Upcoming Releases</h2> <table> <tr> <th>Release</th> <th>Est. Date?</th> <th> Goals </th> </tr> <tr> <td>1.0.1.d200809XX</td> <td>23 September 2008</td> <td> Candidate checkpoint release for 1.1.0. </td> </tr> <tr> <td>1.1.0</td> <td>30 September 2008</td> <td> New features, bug fixes, documentation updates. Prioritization of work items and initial checkins are occuring now. </td> </tr> <tr> <td>1.1.0.d200810XX</td> <td>21 October 2008</td> <td> Candidate checkpoint release for 1.1.1. </td> </tr> <tr> <td>1.1.1</td> <td>28 October 2008</td> <td> Critical bug fixes for 1.1.0. </td> </tr> <tr> <td>1.1.1.d200811XX</td> <td>17 November 2008</td> <td> Candidate checkpoint release for 1.2.0. </td> </tr> <tr> <td>1.2.0</td> <td>24 November 2008</td> <td> New features, bug fixes, documentation updates. </td> </tr> <tr> <td>1.2.0.d200812</td> <td>15 December 2008</td> <td> Candidate checkpoint release for 1.2.1. </td> </tr> <tr> <td>1.2.1</td> <td>22 December 2008</td> <td> Critical bug fixes for 1.2.0. </td> </tr> <tr> <td>2.0</td> <td>19 January 2009 ???</td> <td> First release that will break backwards compatibility with Python 1.5.2. </td> </tr> </table> <!-- <h2>Upcoming Features</h2> --> <h2>Release Planning</h2> <h3>Release numbering</h3> <p> Our release numbers are of the form <i>major</i>.<i>minor</i>.<i>revision</i>. </p> <ul> <li> <strong>Major release (1.0, 2.0, 3.0, etc.)</strong> <p> The major number increments when one of two things happens: <ul> <li>The release knowingly breaks backwards compatibility in some way. <li>The release knowingly causes a rebuild when you upgrade. </ul> 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. </p> </li> <li> <strong>Minor release (1.1, 1.2, 1.3, etc.)</strong> <p> Minor numbers increment for release that adds new functionality and/or bug fixes 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 and fix bugs. </p> </li> <li> <strong>Bug-fix revisions (1.1.1, 1.1.2, 1.1.3, etc.)</strong> <p> Revision numbers are appended and/or incremented whenever a critical bug fix is necessary for a major or minor release. Bedause 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. </p> </li> <li> <strong>Testing pre-release (1.1.90, 1.1.91, 1.1.92, etc.)</strong> <p> A revision 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 (<i>*cough*</i> 0.97 <i>*cough*</i>...). </p> </li> </ul> </div> </body> </html>