1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
<html>
<head>
<title>scons: Release Roadmap</title>
</head>
<body>
<div id="apphead">
<h1><small>Release Roadmap</small></h1>
</div>
<div class="h2 app" style="border-left: 0px" id="customcontent">
<h2>Current Releases</h2>
<p>
The current stable release is 1.0.1, released 7 September 2008.
</p>
<p>
The latest release is 1.0.1, released 7 September 2008.
</p>
<h2>Upcoming Releases</h2>
<p>
Our goal is to meet the dates
for release candidates and the releases themselves;
the beta checkpoint dates are our best guess as this was published,
but they may be adjusted on no notice.
</p>
<table>
<tr>
<th>Estimated date</th>
<th>Type</th>
<th>Name</th>
<th>Comments</th>
</tr>
<tr>
<td>13 September 2008</td>
<td>checkpoint</td>
<td>1.0.1.d20080913</td>
<td>Beta for 1.1. Prioritization of work items and checkins for 1.1 are occuring now.</td>
</tr>
<tr>
<td>27 September 2008</td>
<td>candidate</td>
<td>1.0.1.d20080927</td>
<td>Release candidate for 1.1.</td>
</tr>
<tr>
<td>4 October 2008</td>
<td>release</td>
<td>1.1</td>
<td>First minor release of 1.0.</td>
</tr>
<tr>
<td>11 October 2008</td>
<td>checkpoint</td>
<td>1.1.d20081011</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>25 October 2008</td>
<td>checkpoint</td>
<td>1.1.d20081025</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>8 November 2008</td>
<td>checkpoint</td>
<td>1.1.d20081108</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>15 November 2008</td>
<td>candidate</td>
<td>1.1.d20081115</td>
<td>Release candidate for 1.2.</td>
</tr>
<tr>
<td>22 November 2008</td>
<td>release</td>
<td>1.2</td>
<td>Second minor release of 1.0.</td>
</tr>
<tr>
<td>29 November 2008</td>
<td>checkpoint</td>
<td>1.2.d20081129</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>13 December 2008</td>
<td>checkpoint</td>
<td>1.2.d20081213</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>27 December 2008</td>
<td>checkpoint</td>
<td>1.2.d20081227</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>3 January 2009</td>
<td>candidate</td>
<td>1.2.d20090103</td>
<td>Release candidate for 1.3.</td>
</tr>
<tr>
<td>10 January 2009</td>
<td>release</td>
<td>1.3</td>
<td>Third minor release of 1.0.</td>
</tr>
<tr>
<td>17 January 2009</td>
<td>checkpoint</td>
<td>1.3.d20090117</td>
<td>Beta for testing new featurea; breaks backward compatibility with Python 1.5.2.</td>
</tr>
<tr>
<td>24 January 2009</td>
<td>checkpoint</td>
<td>1.3.d20090124</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>31 January 2009</td>
<td>candidate</td>
<td>1.3.d20090131</td>
<td>Release candidate for 2.0.</td>
</tr>
<tr>
<td>7 February 2009</td>
<td>candidate</td>
<td>1.3.d20090207</td>
<td>Release candidate for 2.0, if needed.</td>
</tr>
<tr>
<td>14 February 2009</td>
<td>release</td>
<td>2.0</td>
<td>Public release that breaks backward compatibility</td>
</tr>
</table>
<!--
<h2>Upcoming Features</h2>
-->
<h2>Release Planning</h2>
<h3>Release numbering</h3>
<p>
Our release numbers are of the form <i>major</i>.<i>minor</i>.<i>revision</i>.
</p>
<ul>
<li>
<strong>Major release (1.0, 2.0, 3.0, etc.)</strong>
<p>
The major number increments when one of two things happens:
</p>
<ul>
<li>The release knowingly breaks backwards compatibility in some way.
<li>The release knowingly causes a rebuild when you upgrade.
</ul>
<p>
Our goal is that as a user of SCons,
you should always be able to upgrade to a later
release of the same major version
with complete confidence that your build will not break.
</p>
</li>
<li>
<strong>Minor release (1.1, 1.2, 1.3, etc.)</strong>
<p>
Minor numbers increment for releases that
add new functionality and/or bug fixes
to an existing major release.
All new functionality will be added so as to never
knowingly break backwards compatibility with any
previous minor releases from the same major release.
We expect that our major releases will be long-lived
platforms for delivering many minor releases to
add functionality and fix bugs.
</p>
</li>
<li>
<strong>Bug-fix revisions (1.1.1, 1.1.2, 1.1.3, etc.)</strong>
<p>
Revision numbers are appended and/or incremented
whenever a critical bug fix is necessary
for a major or minor release.
Bedause most new functionality and bug fixes
will be delivered in minor releases,
we expect that there will be few of these--at most
one per minor release.
</p>
</li>
<li>
<strong>Checkpoints (x.y.dyyyymmdd or x.y.z.dyyyymmdd )</strong>
<p>
A checkpoint has a 'd<i>yyymmdd</i>' suffix
and is made every couple of weeks between major or minor releases.
It is intended for beta testing new features
and for ensuring that bug fixes work as intended.
Although existing features will not change,
compatibility of features under test
is not guaranteed between checkpoints
(<i>i.e.</i>, the implementation of the feature may change).
Checkpoints are intended not only to allow for wider testing,
but also to make new features available to users
who urgently need to use the feature in advance
of it being published in the next major or minor release.
Checkpoints can also act as release candidates
immediately prior to a major or minor release.
</p>
</li>
</ul>
</div>
</body>
</html>
|
