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 1.2.0, released 21 December 2008.
  17 </p>
  18
  19 <p>
  20 The latest release is 1.2.0.d20100117, released 17 January 2010.
  21 </p>
  22
  23 <h2>Upcoming Releases</h2>
  24
  25 <p>
  26 Our goal is to meet the dates
  27 for release candidates and the releases themselves;
  28 the beta checkpoint dates are our best guess as this was published,
  29 but they may be adjusted without notice.
  30 </p>
  31
  32 <!--
  33
  34 DO NOT EDIT THE FOLLOWING TABLE DIRECTLY.
  35
  36 Edit the "schedule" file and replace it with the output from
  37 running "gen_sched_table.py".
  38
  39 -->
  40
  41 <table width="100%">
  42   <tr>
  43     <th>Estimated&nbsp;date</th>
  44     <th>Type</th>
  45     <th>Comments</th>
  46   </tr>
  47   <tr>
  48     <td>5-Dec-2008</td>
  49     <td>RC</td>
  50     <td>Release candidate for 1.2. (released 7-Dec)</td>
  51   </tr>
  52   <tr>
  53     <td>12-Dec-2008</td>
  54     <td>1.2</td>
  55     <td>Second minor release of 1.0. (released 21-Dec)</td>
  56   </tr>
  57   <tr>
  58     <td>29-Dec-2008</td>
  59     <td>Ckpt</td>
  60     <td>Beta for testing new features.</td>
  61   </tr>
  62   <tr>
  63     <td>12-Jan-2009</td>
  64     <td>Ckpt</td>
  65     <td>Beta for testing new features.</td>
  66   </tr>
  67   <tr>
  68     <td>19-Jan-2009</td>
  69     <td>RC</td>
  70     <td>Release candidate for 1.3.</td>
  71   </tr>
  72   <tr>
  73     <td>26-Jan-2009</td>
  74     <td>1.3</td>
  75     <td>Third minor release of 1.0.</td>
  76   </tr>
  77   <tr>
  78     <td>2-Feb-2009</td>
  79     <td>Ckpt</td>
  80     <td>Beta for 2.0; breaks backward compatibility</td>
  81   </tr>
  82   <tr>
  83     <td>9-Feb-2009</td>
  84     <td>RC</td>
  85     <td>Release candidate for 2.0.</td>
  86   </tr>
  87   <tr>
  88     <td>16-Feb-2009</td>
  89     <td>RC</td>
  90     <td>Release candidate for 2.0, if needed.</td>
  91   </tr>
  92   <tr>
  93     <td>23-Feb-2009</td>
  94     <td>2.0</td>
  95     <td>Public release that breaks backward compatibility and drops deprecated features</td>
  96   </tr>
  97   <tr>
  98     <td>16-Mar-2009</td>
  99     <td>Ckpt</td>
 100     <td>Beta for testing new features.</td>
 101   </tr>
 102   <tr>
 103     <td>6-Apr-2009</td>
 104     <td>Ckpt</td>
 105     <td>Beta for testing new features.</td>
 106   </tr>
 107   <tr>
 108     <td>27-Apr-2009</td>
 109     <td>RC</td>
 110     <td>Release candidate for 2.1.</td>
 111   </tr>
 112   <tr>
 113     <td>4-May-2009</td>
 114     <td>2.1</td>
 115     <td>First minor release of 2.0</td>
 116   </tr>
 117 </table>
 118
 119 <!--
 120
 121 <h2>Upcoming Features</h2>
 122
 123 -->
 124
 125 <h2>Release Planning</h2>
 126
 127 <h3>Release numbering</h3>
 128
 129 <p>
 130 Our release numbers are of the form <i>major</i>.<i>minor</i>.<i>revision</i>.
 131 </p>
 132
 133 <ul>
 134 <li>
 135 <strong>Major release (1.0, 2.0, 3.0, etc.)</strong>
 136 <p>
 137 The major number increments when one of two things happens:
 138 </p>
 139   <ul>
 140   <li>The release knowingly breaks backwards compatibility in some way.
 141   <li>The release knowingly causes a rebuild when you upgrade.
 142   </ul>
 143 <p>
 144 Our goal is that as a user of SCons,
 145 you should always be able to upgrade to a later
 146 release of the same major version
 147 with complete confidence that your build will not break.
 148 We expect that our major releases will be long-lived platforms
 149 with many minor releases to add functionality and fix bugs.
 150 </p>
 151 </li>
 152 <li>
 153 <strong>Minor release (1.1, 1.2, 1.3, etc.)</strong>
 154 <p>
 155 Minor numbers increment for releases
 156 that add new functionality and/or bug fixes
 157 to an existing major release.
 158 Any new functionality will never knowingly break backwards compatibility
 159 with any previous minor releases from the same major release.
 160 </p>
 161 </li>
 162 <li>
 163 <strong>Bug-fix revisions (1.0.1, 1.1.1, 1.2.1, etc.)</strong>
 164 <p>
 165 Revision numbers are appended and/or incremented
 166 whenever a critical bug fix is necessary
 167 for a major or minor release.
 168 Because most new functionality and bug fixes
 169 will be delivered in minor releases,
 170 we expect that there will be few of these&mdash;at most
 171 one per minor release.
 172 </p>
 173 </li>
 174 <li>
 175 <strong>Release candidates (x.y.z.dyyyymmdd)</strong>
 176 <p>
 177 A release candidates is a special form of checkpoint
 178 (see below)
 179 that is expected to be the next major or minor release.
 180 If blocking issues show up in the candidate,
 181 another candidate will normally be issued
 182 (potentially delaying the release date),
 183 otherwise the candidate will be repackaged as the major or minor release.
 184 </p>
 185 </li>
 186 <li>
 187 <strong>Checkpoints (x.y.z.dyyyymmdd)</strong>
 188 <p>
 189 A checkpoint has a 'd<i>yyymmdd</i>' suffix
 190 and is made every couple of weeks between major or minor releases.
 191 It is intended for beta testing new features
 192 and for ensuring that bug fixes work as intended.
 193 Although existing features from the previous release will not change,
 194 compatibility of features under test is not guaranteed between checkpoints
 195 (<i>i.e.</i>, the implementation of the feature may change).
 196 Checkpoints are intended not only to allow for wider testing,
 197 but also to make new features available to users
 198 (who may urgently need one of them)
 199 in advance of them being published in the next major or minor release.
 200 </p>
 201 </li>
 202 </ul>
 203
 204 </div>
 205
 206 </body>
 207 </html>