www/roadmap.html

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