Gold Version to do List
We aim to release a gold version of the code early in each year. Here are the steps that we need to take.
What is the gold version
This is the well-tested version which should be used in publications.
It will exist as a separate branch in the svn repository, beneath the /branches directory. The name consists of the last to digits of the year. A branch may have a name like c08_branch. The branch should be created when the new release goes into beta, and no further major changes are expected.
The actual release is a tag created from the release branch, which will be in the /tags/release directory. The tag should have a name like c08.01, where the last two digits indicate the minor release version number: 01 should be used for the first release in a new release series, 02 for the first bug-fix roll-up, etc.
Starting with the c08 release series, we will also post patch updates to each release. These have names like c08.02.01 (this would be the first patch to the c08.02 bug-fix roll-up release), etc. Every time a hot-fix is posted, it should be accompanied by a UNIX patch file. After you applied the hot-fix to the release branch, the first step in the process is to create a tag of the release branch in the /tags/patch_versions directory. You then run an "svn diff" command with the previous patch version. The output of this command should be stored in a file and posted on the hot-fix page. This assures that sequentially applying patch1 through patch<n> takes you exactly from the last release to the current head of the release branch.
For all types of releases (main release, bug-fix roll-up, patch update) make sure that the variables CLD_MAJOR, CLD_MINOR, CLD_PATCH in version.h have values that correspond to the version number in the svn tags directory. For main releases and bug-fix roll-ups CLD_PATCH should be zero.
To do list for creating a gold version
Give the environment variable for the local data path a unique name which includes the version number. It is then possible for many different versions of the code to coexist on the same computer.
Check that there are no blocking tickets on the roadmap.
Use g++ to create dependencies file, include this in the branch
Source directory
Version numbers are date in version.h. Following gives various parts of the version number:
static const int CLD_MAJOR = 8; static const int CLD_MINOR = 1; static const int CLD_PATCH = 0;
If this is a beta version then set nBetaVer in version.h to a non-zero value, 1 for first beta. etc. The flag lgRelease is true if this is a release. If it is true then this says not to print comments about fixits, broken, todo etc. The flags nBetaVer and lgRelease should not both be set - use one or the other.
run entire project through pclint, check for unused headers
check copyright year across all of source
license.txt - has year - based on BSD license
others.txt - this is a list of those who contributed to the code. Check whether it needs to be updated.
readme_source.htm review and confirm still correct
list_headers.pl - This checks on any header files that are not used. It produces following output files; headers.txt is a summary of all header files and listfiles.list with all source files using each header todo_search.pl This makes a prioritized list of todo's, creates todo_table.txt and todo_table.htm, checks no TODO criticality 0
list_routines.pl This creates list of all routines with description and file name. Its output goes into sorttable.html and sortsrc.list extract_atomic_data.pl - This extracts all atomic data references. The files created are: atomicdata.list containing new references and oldatomicdata.list containing old references.
fabden should stop with statement that it needs to be replaced
fudge factors - check that fudge factors are not used
size of code record
make sure Makefile.dep is present and up-to-date
data
readme_data.htm
review and update
*.pl - nothing to be done
Test suite - auto
runall.pl - check that it does not skip any models
readme_tests.htm
review
doc_tsuite.pl
this creates a list of all test cases, including the input commands and a description of its purpose
OUTPUT:
doc_tsuite.txt: contains a tab delimited list of the files,
doc_tsuite.htm: formatted list
valgrind - run on cloud9
checkall.pl
Check for sims close to an assert - this is in close.txt
Check that no debugging information is present - this is listed in debug.txt
Review minor problems - these are listed in minor.txt
Check asserted zones in all sims. Some may be only 1 or two zones from throwing an assert and close.txt will not catch it. Also check on those with number of asserted zones much larger than needed. itrzn check rational, or too close
punch files
Check coverage run to confirm that all punch options are used in at least one of the tests.
CheckPunchSharp.pl Punch files should start with a header saying what the column indicate. The first character should be a sharp sign. This script lists all files that do not start with "#". This is an error, and may indicate that the header was not properly produced.
Test suite - slow
slow tests ok?
programs
run the programs then check the output
run_programs.pl will run the set of programs with either gcc or icc. It obtains a list of the programs from run_programs.dat
Hazy
update tables in Hazy part III
in headinfo check that copyright and citation information is correct,
any other numbers that might have changed
review all word comments in hazy
update table "atomic data sources" in hazy 3
update all fields, check for missing cross references
cloudy size growth in hazy 3
update table model test suite in hazy 3
check whether in press papers in references have appeared
create PDF
check that page numbers are correct (were not in Jul 05 release)
check that links are hot - click on page number to go there
(were not hot in Jul 05 release)
create PDF using "web gary" with jaws, view document to confirm that greeks are embedded properly
copy to web site
source, data, test suite, from last or last good dir
slow from tsuite/slow
hazy files programs from tsuite/programs
output files from full set of machines
post on front page of web site
make discussion group announcement
create branch in repository
Return to DeveloperPages
Return to main wiki page
Return to nublado.org
