Release Version |
0.4.2 |
Release Manager |
Anonymous |
Release Date |
November 2007 |
The onset of a major or minor release should come as no surprise to all the developers involved in the project. It is vital at a release that the developers all agree what is to be included in the release, what is to be retired (or deprecated) in this release, and what is to be added in some future release. Normally this process should be handled as a release issue in the tracker.
|
Draw up an announcement text file. |
||
date |
date |
||
|
Draw up matching RETIRED and NOT_YET files. |
||
n/a |
|||
|
Given announcement file, have developers commit to a code freeze date/time. |
||
date |
|||
|
configure.ac, scripts/bocca |
||
date |
|||
|
additional file changes for release |
||
date |
|||
The following files should be verified as up-to-date in the root directory. Furthermore, they should all be listed in the EXTRA_DIST macro in the Makefile.am file.
|
README |
|
||
11/8/2006 |
||||
|
|
|
||
11/8/2006 |
||||
|
|
|||
11/8/2006 |
||||
|
CHANGES |
|
||
11/8/2006 |
||||
|
BUGS |
|
||
11/8/2006 |
||||
|
ANNOUNCE |
|
||
11/8/2006 |
||||
|
LICENSE |
|
||
11/8/2006 |
||||
More appropriately called a "feature freeze", the purpose is to enter a special mode of code development where no new features are added to the code. In fact, once this phase is entered, no edits to any file should be made except to fix bugs -- whether it be in source code, supporting files, or documentation.
|
Verify check-in of all scheduled code deliverables. |
||
11/8/2006 |
|||
|
Generate new documentation as needed from tex sources. |
||
11/8/2006 |
|||
|
Copy all relevant HTML, Postscript and PDF files to source
directory (bocca/doc/manuals/). |
||
11/8/2006 |
|||
|
Email all developers that the code is now officially "frozen". |
||
11/9/2006 |
|||
|
Verify that no reference to the previous version of the
code exists where it shouldn't. |
||
11/9/2006 |
|||
|
|
||
11/9/2006 |
|||
Any feature or functionality mentioned in the ANNOUNCE file should be verified. Ideally, this verification can be done by confirmation of a test or suite of tests executed by the traditional 'gmake check' command.
|
Confirm existence and successful execution of a test script for each new feature. (Failure to confirm is considered a bug worthy of editing or adding to the frozen code) |
||
Skipped |
|||
|
Confirm supporting documentation accurately represents the feature. (Failure to confirm is considered a bug and worthy of editing the frozen documentation.) |
||
Skipped |
|||
Testing should, in fact, be done in concert with code development. Any code that breaks at this stage of the release cycle, on the primary development platform (linux gcc4, osx gcc4) should be a big surprise and possibly trigger a re-evaluation of the entire release cycle. Nonetheless, every developer cannot be expected to run extensive testing on all supported platforms daily, so portability testing is required.
Any failure of any test on any platform must be resolved by either (1) fixing the bug, or (2) changing the test to "expected failure" (XFAIL). The latter must be agreed upon by the development team and an entry must be made in the BUGS file in the root directory and Bugzilla.
NOTE: Whenever a bug is found and fixed, all previous tests are invalid and must be rerun.
The process involves performing "make distcheck", at least on the official development platform. An alternative for other platforms is to simply perform "make check" with the distribution tarball created from the official development platform. (Note the latter approach was not employed for this release.)
NOTE: The flags listed under "Config" below represent general settings but do not necessarily reflect all compiler flags needed for each of the three compilers. For the actual settings, check the appropriate profile file found in the regression/cronjobs directory.
Machine |
Compiler |
Config |
Packages |
Regression Test Parts |
Date |
|||
---|---|---|---|---|---|---|---|---|
PASS |
XFAIL |
FAIL |
BROKEN |
|||||
qc.ca.sandia.gov |
py2.5/babel1.0.6 |
? |
. |
. |
. |
. |
. |
comment |
? |
. |
. |
. |
. |
. |
. |
||
py2.5/babel1.0.8 |
|
|
18561 |
17 |
0 |
0 |
7/21/2006 (distcheck passed) |
|
?py2.3/babel 1.0.6 |
|
|
18561 |
17 |
0 |
0 |
7/20/2006 (opt version) |
|
? |
-g -O2 |
|
18561 |
17 |
0 |
0 |
7/21/2006 |
|
osx/norris |
? |
? |
|
18511 |
17 |
.0 |
.10 |
7/21/2006 (broken tests fixed and verified) |
? |
. |
. |
. |
. |
. |
. |
||
? |
-? |
. |
. |
. |
. |
. |
. |
|
-? |
. |
. |
|
. |
. |
Failed** |
||
? |
-? |
. |
. |
. |
. |
. |
Failed** |
|
-? |
. |
. |
. |
. |
. |
. |
||
linux/wael |
gcc/g++/g77 |
-g |
. |
. |
. |
. |
. |
. |
-O |
. |
. |
. |
. |
. |
. |
||
icc/icpc/f77/ifort |
-g |
. |
18566 |
12 |
0 |
0 |
7/21/2006 |
|
-O |
. |
. |
. |
. |
. |
. |
||
kcc/KCC/kf77 |
-g |
. |
. |
. |
. |
. |
. |
|
-O |
. |
. |
. |
. |
. |
. |
||
osx/rob |
py=? |
-g |
. |
. |
. |
. |
. |
. |
-O |
. |
. |
. |
. |
. |
. |
||
newxlc/newxlC/newxlf77/newxlf90 |
-g |
. |
. |
. |
. |
. |
. |
|
-O |
. |
12622 |
4 |
. |
. 24 |
comment |
Notes here..
more notes here
<>* footnote
** footnote
*** footnote
After code has passed all the tests, all the supporting files are updated, and all the documentation has been updated, it is time to actually create a release. Be sure to use the regular options (i.e., do not utilize the optimization options).
|
Perform a final check for memory leaks (once it's
working) result summary. Here are the results. =result details. |
||
date |
|||
|
Perform a final check on at least one development
platform. |
|||
date |
||||
|
Create SVN version and branch for major release. Create the tag for diff purposes. fixes happen on the x branch. For patch releases, just do the tag copy below. svn copy
svn+ssh://cca-forum.org/home/svn/bocca/branches/release-0.4.x-branch
svn+ssh://cca-forum.org/home/svn/bocca/tags/release-0.4.2 -m
"Create tag for bocca 0.4.2." |
|||
11/9/2006 |
||||
|
For major stable releases, immediately bump the version tag in configure and scripts/bocca on up to the next unstable number. No feature development happens on the stable branches ever. |
|||
date |
||||
After the tarball has been created, it needs to be advertised and deployed appropriately (and extensively).
|
Add the new release number to the Bugzilla Tracking system |
||||||||||||||||||
1/30/2004 |
|||||||||||||||||||
|
|
||||||||||||||||||
|
Update Project wiki page |
||||||||||||||||||
8/18/2004 |
|||||||||||||||||||
|
|||||||||||||||||||
|
|
copy file to cca-forum.org/download/bocca |
|||||||||||||||||
|
|
Confirm pages in place |
|||||||||||||||||
|
|
||||||||||||||||||
|
Install at the following sites |
||||||||||||||||||
3/xx/2003 |
|
||||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
||||||||||||||||||
|
Email the ANNOUNCE file to the following reflectors |
||||||||||||||||||
1/30/2004 |
|
||||||||||||||||||
|
|
cca-forum@cca-forum.org |
|||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
? |
|||||||||||||||||
|
|
? |
|||||||||||||||||