I've made the release.
I'll leave it there for a few days before any announcements.
For the purposes of documenting things I've learnt:
1. Download everything first onto at least two platforms and test the
current CVS HEAD. THe dashboards can be wrong (They never noticed that the
root configure filres had been removed!) This includes updating CHANGES.txt.
2. The following is a description of how to make a branch point and branch
(Thanks to Brad for the info)(This only applies to making a new minor
version release, not a patch release)
cvs up -PdA
cvs tag vxl-1-0-bp
cvs tag -b vxl-1-0
3. Move to the branch
cvs up -r vxl-1-0
4. Do some release specific work
Make sure that core/vxl_version.h is correct.
Update CHANGES.txt to mention the new release.
Copy in an INSTALL.html (e.g. from the website)
5. Tag the 1.0.0 release:
cvs tag vxl-1-0-0
5A. If you end up in a mess (e.g. because SF will not recognise that
configure really shouldn't be in the CVS attic) you can abandon the branches
and tags you have made so far. You can fix everything in the main CVS
branch, and commit it there. Then simply retag everything with the -F
option, which will make it forget about the previous locations of the tags.
It is not recommended to do this if these tags have had any other users but
cvs up -PdA
cvs tag -F vxl-1-0-bp
cvs tag -bF vxl-1-0
6. Create a vxl download into directory.
Do this on a Unix box so that the execute permissions are
preserved. use cvs export to strip the CVS directories.
cvs export -r vxl-1-0-0 -d vxl-1.0.0 vxl
7. Tar it up, and test the tar file from scratch on at
least two platforms.
8. Submit it to the Sourceforge File Release system.
9. Get a copy of the documentation build, tar it up, and submit it to the
File Release System.
10. Did I mention that testing is good. Try downloading the files from
SourceForge. It can go wrong even now.
11. Submit a email describing the release to vxl-users, vxl-announce, and
submit a news item at VXL's SourceForge project page.