Note: these are incomplete
type | sample |
---|---|
local variable | shunit_someVariable_ |
global variable | __shunit_someVariable |
public constant | SHUNIT_TRUE |
private constant | __SHUNIT_SHELL_FLAGS |
public function | assertEquals |
private function | _shunit_someFunction |
macro | _SHUNIT_SOME_MACRO_ |
This project is stored on code.google.com as http://code.google.com/p/shunit2/. All releases as of 2.1.4 and full source are available there. Documentation is included as part of the source and each release. Source code is stored in Subversion and can be accessed using the following information.
Browse the code in a web browser:
Check out the code locally
$ svn checkout http://shunit2.googlecode.com/svn/trunk/ shflags-read-only
DEPRECATED
This project is stored on SourceForge as http://sf.net/projects/shunit2. The source code is stored in Subversion and can be accessed using the following information.
Check out the code locally
$ svn co https://shunit2.svn.sourceforge.net/svnroot/shunit2/trunk/source/2.1 shunit2
Browse the code in a web browser:
For these steps, it is assumed we are working with release 2.0.0.
Steps:
This should be pretty self explainatory. Use one of the release notes from a previous release as an example.
To get the versions of the various shells, do the following:
Shell | OS | Notes |
---|---|---|
bash | $ bash --version | |
dash | Linux | $ dpkg -l |grep dash |
ksh | $ ksh --version -or- $ echo 'echo $KSH_VERSION' |ksh | |
Cygwin | see pdksh | |
Solaris | $ strings /usr/bin/ksh |grep 'Version' | |
pdksh | $ strings /bin/pdksh |grep 'PD KSH' | |
Cygwin | look in the downloaded Cygwin directory | |
sh | Solaris | not possible |
zsh | $ zsh --version |
Alternativly, a version_info.sh script is included in the bin directory that provides similar information.
Edit src/shell/shunit2 and change the version number in the comment, as well as in the SHUNIT_VERSION variable. Next, edit the src/docbook/shunit2.xml file, edit the version in the <title> element, and make sure there is a revision section for this release.
Make sure that any remaning changes get put into the CHANGES-X.X.txt file.
Finish writing the RELEASE_NOTES-X.X.X.txt. Once it is finished, run it through the fmt command to make it pretty.
$ fmt -w 80 RELEASE_NOTES-2.0.0.txt >RELEASE_NOTES-2.0.0.txt.new $ mv RELEASE_NOTES-2.0.0.txt.new RELEASE_NOTES-2.0.0.txt
We want to have an up-to-date version of the documentation in the release, so we'd better build it.
$ pwd .../shunit2/source/2.0 $ make docs ... $ cp -p build/shunit2.html doc $ rst2html --stylesheet-path=share/css/rst2html.css doc/README.txt >doc/README.html
This step is pretty self-explainatory
$ pwd .../shunit2/source/2.0 $ svn ci -m "finalizing release"
$ pwd .../shunit2/source $ ls 2.0 2.1 $ svn cp -m "Release 2.0.0" 2.0 https://shunit2.googlecode.com/svn/tags/source/2.0.0
$ pwd .../shunit2/builds $ svn export https://shunit2.googlecode.com/svn/tags/source/2.0.0 shunit2-2.0.0
$ tar cfz ../releases/shunit2-2.0.0.tgz shunit2-2.0.0
$ cd ../releases $ md5sum shunit2-2.0.0.tgz >shunit2-2.0.0.tgz.md5 $ gpg --default-key kate.ward@forestent.com --detach-sign shunit2-2.0.0.tgz
Again, pretty self-explainatory. Make sure to copy the MD5 and GPG signature files. Once that is done, make sure to tag the website so we can go back in time if needed.
$ pwd .../shunit2 $ ls source website $ svn cp -m "Release 2.0.0" \ website https://shunit2.googlecode.com/svn/tags/website/20060916
Now, update the website. It too is held in Subversion, so ssh into the web server and use svn up to grab the latest version.