The VisIt release process typically takes place every 3-4 months, depending on the complexity of the enhancements and bug-fixes going into a release. This page will eventually describe the procedure that is followed for releasing a new version of VisIt as well as a check list template that can be used to track the progress of items within the release process.
Checklist for the release
This is a strawman for a release checklist.
- Typically, but not always, the VisIt Project Leader serves as the Release Manager
- Sometimes, the VisIt Project leader may delegate this responsibility to someone else on the team. If so, the team should be informed of such delegation.
- The Release Manager is responsible for tracking all the work to be completed for the release as well as completing all the steps of the release process.
- In particular, no one other than the Release Manager should be involved in making the final repository changes for the release.
- Release Manager announces proposed date for creating the release candidate.
- Release candidate is created using script "mktag".
- Changes are made to accommodate the new release number
- On the trunk:
- The file "Version" is updated for the next release.
- The splash screen is updated for the next release.
- The new release notes file is created for the next release.
- On the RC:
- "build_visit" script is updated to have the VISIT_VERSION variable point at the new release on the RC and merged to the trunk.
- The build_notes (general and Mac) are updated to reference a build_visit that's link is for the current version.
- On the trunk:
- The release candidate is finalized
- Developers put their final fixes (guaranteed to be safe) onto the release candidate
- Each developer makes sure all of their changes are placed into the release notes
- Preliminary builds are made on major platforms.
- (TODO) The release candidate branch is tested independently of trunk
- The VisIt project leader declares all work on the release candidate should be frozen
- The release candidate is tagged
- The VERSION file on the RC is updated to the next patch release number
- A new release notes file is started on the RC
- Final builds are made for each platform from the tag (not RC or trunk)
- Release builds are uploaded to the repository in trunk/releases/<version-no>
- Instead of having to checkout the releases directory, it's easiest to use the svn import command to upload releases directly to that directory like so. . .
svn import -m 'your comment here' <file-to-add> svn+ssh://email@example.com/project/projectdirs/visit/svn/visit/trunk/releases/2.10.0/<file-to-add>
- md5, sha1 and sha256 checksums are computed for all downloadable release files
- These checksums are to be posted to the web but, more imortantly, also sent in the email announcing the release. The rational for this is that it is more secure to broadcast these checksums in email to many users making it difficult for attackers to hack both the download files and the checksums
- The builds are posted on the web
- The new release is installed at participating sites
- The new release is announced via firstname.lastname@example.org
- The email includes checksums of the files