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
|
<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.2.0, released 21 December 2008.
</p>
<p>
The latest release is 1.2.0.d20090113, released 13 January 2009.
</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 without notice.
</p>
<!--
DO NOT EDIT THE FOLLOWING TABLE DIRECTLY.
Edit the "schedule" file and replace it with the output from
running "gen_sched_table.py".
-->
<table width="100%">
<tr>
<th>Estimated date</th>
<th>Type</th>
<th>Comments</th>
</tr>
<tr>
<td>5-Dec-2008</td>
<td>RC</td>
<td>Release candidate for 1.2. (released 7-Dec)</td>
</tr>
<tr>
<td>12-Dec-2008</td>
<td>1.2</td>
<td>Second minor release of 1.0. (released 21-Dec)</td>
</tr>
<tr>
<td>29-Dec-2008</td>
<td>Ckpt</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>12-Jan-2009</td>
<td>Ckpt</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>19-Jan-2009</td>
<td>RC</td>
<td>Release candidate for 1.3.</td>
</tr>
<tr>
<td>26-Jan-2009</td>
<td>1.3</td>
<td>Third minor release of 1.0.</td>
</tr>
<tr>
<td>2-Feb-2009</td>
<td>Ckpt</td>
<td>Beta for 2.0; breaks backward compatibility</td>
</tr>
<tr>
<td>9-Feb-2009</td>
<td>RC</td>
<td>Release candidate for 2.0.</td>
</tr>
<tr>
<td>16-Feb-2009</td>
<td>RC</td>
<td>Release candidate for 2.0, if needed.</td>
</tr>
<tr>
<td>23-Feb-2009</td>
<td>2.0</td>
<td>Public release that breaks backward compatibility and drops deprecated features</td>
</tr>
<tr>
<td>16-Mar-2009</td>
<td>Ckpt</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>6-Apr-2009</td>
<td>Ckpt</td>
<td>Beta for testing new features.</td>
</tr>
<tr>
<td>27-Apr-2009</td>
<td>RC</td>
<td>Release candidate for 2.1.</td>
</tr>
<tr>
<td>4-May-2009</td>
<td>2.1</td>
<td>First minor release of 2.0</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.
We expect that our major releases will be long-lived platforms
with many minor releases to add functionality and fix bugs.
</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.
Any new functionality will never knowingly break backwards compatibility
with any previous minor releases from the same major release.
</p>
</li>
<li>
<strong>Bug-fix revisions (1.0.1, 1.1.1, 1.2.1, etc.)</strong>
<p>
Revision numbers are appended and/or incremented
whenever a critical bug fix is necessary
for a major or minor release.
Because 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>Release candidates (x.y.z.dyyyymmdd )</strong>
<p>
A release candidates is a special form of checkpoint
(see below)
that is expected to be the next major or minor release.
If blocking issues show up in the candidate,
another candidate will normally be issued
(potentially delaying the release date),
otherwise the candidate will be repackaged as the major or minor release.
</p>
</li>
<li>
<strong>Checkpoints (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 from the previous release 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 may urgently need one of them)
in advance of them being published in the next major or minor release.
</p>
</li>
</ul>
</div>
</body>
</html>
|
