How To Make A Release
|Revision as of 17:04, 25 April 2006
Wayne (Talk | contribs)
← Previous diff
|Revision as of 17:40, 28 April 2006
Wayne (Talk | contribs)
Next diff →
|Line 112:||Line 112:|
|-||6) Update web pages (various ones) and email srb-chat, srb-news, and||+||6) Update web(wiki) pages (various ones) and email srb-chat, srb-news, and|
|Paul Tooby firstname.lastname@example.org.||Paul Tooby email@example.com.|
|-||The ReleaseNotes file is html, so to send the email you might display it in a browser and cut and paste it to make it semi-formated plain-text. I like to include a link to the on-line html version in the email.||+||Include the URL of the Release Notes and the highlight headings.|
|-||7) Client-only and some binary distributions should be added to the web site sometime after the release (a few days is probably OK). There is a script to create the client-only release in the readme.dir/client_only_releases subdirectory.||+||7) Client-only and some binary distributions should be added to the web site sometime after the release (a few days is probably OK). There is a script to create the client-only release in the releases/client_only subdirectory.|
Revision as of 17:40, 28 April 2006
Here are some notes on how to make releases.
Whenever one of these minor releases is created, the tree will be tagged. If needed, you can checkout a particular version of the SRB2 tree to a directory of your choosing, e.g.
cvs checkout -r Release2_1_2 -d SRB-2.1.2-debug
How to make a Release:
(Be sure you are working in a directory with the current version of the code tree)
1) Create a Release_Notes_X_Y_Z wiki file describing the release.
2) If it hasn't been done already, change the SRB_VERSION number for the system
Go into the top level directory and change the SRB_VERSION number in configure.in, run autoconf, checkin configure.in and configure, e.g.:
emacs configure.in autoconf (be sure you are using a recent version) (there is currently a bug in the configure script that requires some editing after running autoconf; so be sure to do this (see configure.readme.srbteam) cvs commit -m "Updated SRB_VERSION number" configure.in configure
Instead of the above, you can also just edit both configure.in and configure to change the version number. It is one line in each, identified with SRB_VERSION=.
2b) If the man pages have changed, cd to utilities/man and run the makeHTML.sh script to create a new srbcommands.html file and a complete new set of html files in the html subdirectory (Sinit.1.html, etc), and commit those into CVS. With the new wiki system, we no longer put this on the web site but you might confirm that the authors have updated the wiki man pages to match the .1 files.
3) tag the current version
tag the current version of all the files, recursively, with an appropriate tag for the version you are creating (since CVS does not like "."s, use _ instead, e.g.
cvs tag Release2_1_2
(this immediately records it in the repository, no need to commit)
(If you have to check in more stuff later, and then set it to the same
tag (reset the tag), use: cvs tag -F Release2_1_2 files
4) Checkout a clean version of the latest code to make sure you don't get anything that isn't checked in, e.g.
cvs checkout SRB2
cvs checkout -d SRB2.1.2 SRB2
cvs checkout -r Release2_1_2 -d SRB2.1.2 SRB2
Quite a while ago, we created an alias for the source repository so that either SRB2 or SRB2_0_0rel will work fine, since this is the repository for all the releases.
We had trouble with using the "cvs export" command, as we need the empty directories; so just a simple "cvs checkout" seems to work best altho it does create the CVS directories/files.
Currently, we need to remove the utilities/bin/Sput.pl and Sget.pl scripts before making the release. So do this by hand after the checkout.
We use to remove the inQ subdirectory, but now we leave it in place as inQ is to be included in the release.
Also remove the subdirectories under mySRB, leaving just the README.mySRB file (which refers to the web page).
5) Make encrypted tar files
(I have a script, in ~schroede/perl/mktar.pl, that helps with this; but you need to check what it does and edit some parameters.)
We now need to create 4 tar files, encrypted with pgp or openssl and with either the edu or gov copyright files. So the steps below need to be repeated. Our naming conventions for this are:
SRB3.0.1relg_bf.tar Gov, openssl(blowfish) encrypted SRB3.0.1rele_bf.tar Edu, openssl(blowfish) encrypted SRB3.0.1relg_pgp.tar Gov, pgp encrypted SRB3.0.1rele_pgp.tar Edu, pgp encrypted
Remove COPYRIGHT/Copyright.gov when making the Edu tar files, and put it back remove COPYRIGHT/Copyright.edu when making the Gov tar files.
Fix bug 203 (permissions of the man pages and source files in the SRB tar file), if needed. We think the permissions should be OK now, but if not:
find SRB2.1.2 -name '*.[hc]' -print | xargs chmod o-x,g-x,o-r,g+r find SRB2.1.2 -name '*.1' -print | xargs chmod a-x,o+r
then tar up the code:
tar cf SRB2.1.2.tar SRB2.1.2
(don't use compression since some sites may have trouble with that and pgp will compress it itself.)
pgp -c SRB2.1.2.tar -o srb (this will prompt for the password) mv srb.pgp SRB2.1.2rel_pgp.tar
openssl enc -e -bf -in SRB2.1.2.tar -out SRB2.1.2rel_bf.tar (this will prompt for the password)
These encrypted files go on our web site under tarfiles.
6) Update web(wiki) pages (various ones) and email srb-chat, srb-news, and Paul Tooby firstname.lastname@example.org.
Include the URL of the Release Notes and the highlight headings.
7) Client-only and some binary distributions should be added to the web site sometime after the release (a few days is probably OK). There is a script to create the client-only release in the releases/client_only subdirectory.