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