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