www/roadmap.html

   1 <html>
   2 <head>
   3 <title>scons: Release Roadmap</title>
   4 </head>
   5 <body>
   6
   7 <div id="apphead">
   8 <h1><small>Release Roadmap</small></h1>
   9 </div>
  10
  11 <div class="h2 app" style="border-left: 0px" id="customcontent">
  12
  13 <h2>Current Releases</h2>
  14
  15 <p>
  16 The current stable release is 0.96.1, released 23 August 2004.
  17 </p>
  18
  19 <p>
  20 The current testing pre-release is 0.96.92, released 10 April 2006.
  21 </p>
  22
  23 <p>
  24 (Yes, the current "stable" release is a little long in the tooth.
  25 In practice, most everyone uses the testing pre-releases,
  26 because our testing methodology gives us a pretty good
  27 track record of not breaking things from release to release.)
  28 </p>
  29
  30 <h2>Upcoming Releases</h2>
  31
  32 Take these with a huge grain of salt,
  33 this is very rough planning
  34 and subject to change.
  35
  36 <table>
  37 <tr>
  38 <th>Release</th>
  39 <th>Est. Date?</th>
  40 <th>
  41 Goals
  42 </th>
  43 </tr>
  44 <tr>
  45 <td>0.96.93</td>
  46 <td>???</td>
  47 <td>
  48 The last (?) pre-release before the "Big Signature Refactoring"
  49 changes internal data structures.
  50   <ul>
  51   <li>
  52   Fix for the one regression found so far in 0.96.92
  53   (printing an incorrect message when executing the InstallAs() function)
  54   </li>
  55   <li>
  56   Significant speed up of some specific configurations
  57   </li>
  58   <li>
  59   Integration of accumulated patches with bug fixes and new functionality
  60   </li>
  61   </ul>
  62 </td>
  63 </tr>
  64 <tr>
  65 <td>0.96.94</td>
  66 <td>???</td>
  67 <td>
  68 Testing pre-release of the "Big Signature Refactoring,"
  69 a significant re-design of internal data structures
  70 to accomplish the following:
  71   <ul>
  72   <li>
  73   Interoperability between MD5 signatures and timestamps
  74   </li>
  75   <li>
  76   Ability to partition the dependency graph into separate <tt>SConstruct</tt>
  77   (not just <tt>SConscript</tt>) files.
  78   </li>
  79   <li>
  80   Hooks for supporting tool-generated dependency information
  81   (like <tt>gcc -M</tt>)
  82   </li>
  83   <li>
  84   Improved performance (we hope)
  85   </li>
  86   </ul>
  87 </td>
  88 </tr>
  89 <tr>
  90 <td>0.97</td>
  91 <td>???</td>
  92 <td>
  93 Wider release and more extensive field testing before
  94 declaring the "Big Signature Refactoring"
  95 ready to be blessed as the official 1.0 release.
  96 Additional features and bug fixes.
  97 </td>
  98 </tr>
  99 <tr>
 100 <td>1.0</td>
 101 <td>???</td>
 102 <td>
 103 First official, stable release.
 104 No 1.x release will (knowingly) break compatibility
 105 or cause a rebuild on upgrade.
 106 The following features have been suggested as prerequisites
 107 for a fully-feature 1.0 release:
 108   <ul>
 109   <li>
 110   C/C++ dependency scanning that acts like a real C preprocessor
 111   (computed file names, <tt>#ifdef</tt> analysis, <tt>#include_next</tt> support)
 112   </li>
 113   </ul>
 114 </td>
 115 </tr>
 116 <tr>
 117 <td>2.0</td>
 118 <td>???</td>
 119 <td>
 120 First release that will break backwards compatibility with Python 1.5.2.
 121 </td>
 122 </tr>
 123 </table>
 124
 125 <!--
 126
 127 <h2>Upcoming Features</h2>
 128
 129 -->
 130
 131 <h2>Release Planning</h2>
 132
 133 <h3>Why has 1.0 still not been released?</h3>
 134
 135 <p>
 136 As seems so common these days,
 137 SCons has had an extremely lengthy "beta" period.
 138 The primary goal has been to arrive at something by 1.0
 139 that we feel is absolutely rock-solid-stable
 140 and which people can download and use without fear of
 141 broken builds or unnecessary rebuilds.
 142 To get some idea of how we do this, see our
 143 <a href="testing.html">testing philosophy</a> page.
 144 </p>
 145
 146 <h3>Release numbering</h3>
 147
 148 <p>
 149 Our release numbers are of the form <i>major</i>.<i>minor</i>.<i>revision</i>.
 150 </p>
 151
 152 <ul>
 153 <li>
 154 <strong>Major release (1.0, 2.0, 3.0, etc.)</strong>
 155 <p>
 156 The major number increments when one of two things happens:
 157   <ul>
 158   <li>The release knowingly breaks backwards compatibility in some way.
 159   <li>The release knowingly causes a rebuild when you upgrade.
 160   </ul>
 161 Our goal is that as a user of SCons,
 162 you should always be able to upgrade to a later
 163 revision of the same major number
 164 with complete confidence that your build will not break.
 165 </p>
 166 </li>
 167 <li>
 168 <strong>Minor release (1.1, 1.2, 1.3, etc.)</strong>
 169 <p>
 170 Minor numbers increment for release that
 171 adds new functionality and/or bug fixes
 172 to an existing major release branch.
 173 All new functionality will be added so as to never
 174 knowingly break backwards compatibility with any
 175 previous minor releases from the same branch.
 176 We expect that our major release branches will be long-lived
 177 platforms for delivering many minor releases to
 178 add functionality and fix bugs.
 179 </p>
 180 </li>
 181 <li>
 182 <strong>Bug-fix revisions (1.1.1, 1.1.2, 1.1.3, etc.)</strong>
 183 <p>
 184 Revision numbers are appended and/or incremented
 185 whenever a critical bug fix is necessary
 186 for a major or minor release.
 187 Bedause most new functionality and bug fixes
 188 will be delivered in minor releases,
 189 we expect that there will be few of these--at most
 190 one per minor release.
 191 </p>
 192 </li>
 193 <li>
 194 <strong>Testing pre-release (1.1.90, 1.1.91, 1.1.92, etc.)</strong>
 195 <p>
 196 A revision number of 90 or greater
 197 indicates the release is intended for
 198 testing a set of new features intended for
 199 wider distribution in the next major or minor release.
 200 There may be many of these
 201 leading up to a release
 202 with a lot of significant internal changes
 203 (<i>*cough*</i> 0.97 <i>*cough*</i>...).
 204 </p>
 205 </li>
 206 </ul>
 207
 208 </div>
 209
 210 </body>
 211 </html>