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 Significant speed up of some specific configurations,
  44 plus accumulated patches with bug fixes and new functionality.
  45 Fix for the one regression found so far in 0.96.92
  46 (printing an incorrect message when executing the InstallAs() function).
  47 </td>
  48 </tr>
  49 <tr>
  50 <td>0.96.94</td>
  51 <td>???</td>
  52 <td>
  53 Testing pre-release of the "Big Signature Refactoring,"
  54 a significant re-design of internal data structures
  55 to accomplish the following:
  56   <ul>
  57   <li>
  58   Interoperability between MD5 signatures and timestamps.
  59   </li>
  60   <li>
  61   Ability to partition the dependency graph into separate SConstruct
  62   (not SConscript) files.
  63   </li>
  64   <li>
  65   Hooks for supporting tool-generated dependency information
  66   (like <tt>gcc -M</tt>)
  67   </li>
  68   <li>
  69   Improved performance (we hope)
  70   </li>
  71   </ul>
  72 </td>
  73 </tr>
  74 <tr>
  75 <td>0.97</td>
  76 <td>???</td>
  77 <td>
  78 Wider release and more extensive field testing before
  79 declaring the "Big Signature Refactoring"
  80 ready to be blessed as the official 1.0 release.
  81 Additional features and bug fixes.
  82 </td>
  83 </tr>
  84 <tr>
  85 <td>1.0</td>
  86 <td>???</td>
  87 <td>
  88 First official, stable release.
  89 No 1.x release will (knowingly) break compatibility
  90 or cause a rebuild on upgrade.
  91 The following features have been suggested as prerequisites
  92 for a fully-feature 1.0 release:
  93   <ul>
  94   <li>
  95   C/C++ dependency scanning that acts like a real C preprocessor
  96   (computed file names, #ifdef analysis)
  97   </li>
  98   </ul>
  99 </td>
 100 </tr>
 101 <tr>
 102 <td>2.0</td>
 103 <td>???</td>
 104 <td>
 105 First release that will break backwards compatibility with Python 1.5.2.
 106 </td>
 107 </tr>
 108 </table>
 109
 110 <!--
 111
 112 <h2>Upcoming Features</h2>
 113
 114 -->
 115
 116 <h2>Release Planning</h2>
 117
 118 <h3>Why has 1.0 still not been released?</h3>
 119
 120 <p>
 121 As seems so common these days,
 122 SCons has had an extremely lengthy "beta" period.
 123 The primary goal has been to arrive at something by 1.0
 124 that we feel is absolutely rock-solid-stable
 125 and which people can download and use without fear of
 126 broken builds or unnecessary rebuilds.
 127 To get some idea of how we do this, see our
 128 <a href="testing.html">testing philosophy</a> page.
 129 </p>
 130
 131 <h3>Release numbering</h3>
 132
 133 <p>
 134 Our release numbers are of the form <i>major</i>.<i>minor</i>.<i>sub</i>.
 135 </p>
 136
 137 <ul>
 138 <li>
 139 <strong>Major release (1.0, 2.0, 3.0, etc.)</strong>
 140 <p>
 141 The major number increments when one of two things happens:
 142   <ul>
 143   <li>The release knowingly breaks backwards compatibility in some way.
 144   <li>The release knowingly causes a rebuild when you upgrade.
 145   </ul>
 146 Our goal is that as a user of SCons,
 147 you should always be able to upgrade to a later
 148 revision of the same major number
 149 with complete confidence that your build will not break.
 150 </p>
 151 </li>
 152 <li>
 153 <strong>Minor release (1.1, 1.2, 1.3, etc.)</strong>
 154 <p>
 155 Minor releases will add new functionality to an
 156 existing major release branch.
 157 All new functionality will be added so as to never
 158 knowingly break backwards compatibility with any
 159 previous minor releases from the same branch.
 160 We expect that our major release branches will be long-lived
 161 platforms for delivering many minor releases to
 162 add functionality.
 163 </p>
 164 </li>
 165 <li>
 166 <strong>Bug-fix release (1.1.1, 1.1.2, 1.1.3, etc.)</strong>
 167 <p>
 168 Sub-release numbers are used
 169 whenever a critical bug fix is necessary
 170 for a major or minor release.
 171 </p>
 172 </li>
 173 <li>
 174 <strong>Testing pre-release (1.1.90, 1.1.91, 1.1.92, etc.)</strong>
 175 <p>
 176 A sub-release number of 90 or greater
 177 indicates the release is intended for
 178 testing a set of new features intended for
 179 wider distribution in the next major or minor release.
 180 There may be many of these
 181 leading up to a release
 182 with a lot of significant internal changes
 183 (<i>*cough*</i> 0.97 <i>*cough*</i>...).
 184 </p>
 185 </li>
 186 </ul>
 187
 188 </div>
 189
 190 </body>
 191 </html>