- Make sure that all files making up the release are committed to Subversion.
(Eg use 'svn status'.) (Automatically generated files etc are an
exception to this rule: see the "Using Subversion" document.)
- Increment the version number in version.h if necessary (every time a
release is given to a third party -- thus allowing us to identify
which source code was used in any given installation). Commit it into
svn. Example log message: "Changing version number to 1.64."
- Document the release in the lib-tkeden/change.log file. You will need
to look through the log messages for all the Subversion commits since
the last release. If the commit was not made by you, give credit for
this change by adding the author's name in square brackets after the
detail of that change. For example, the change.log for release 1.61
includes the line:
Added builtin 'realrand()'. [ant]
Note that within each version section, the changes are listed in order
of occurrance (approx).
Add a release header to the change.log file: for example:
************************************************************************
1.64 [Ashley] Fri Jul 8 16:25:47 BST 2005
************************************************************************
(Copy and paste the ***s from another release so that you get the right
number.) Put your name (as the person making the release) next to the
version number as shown above. Run the command 'date' on the machine you
are using to make the release, and copy and paste the output to produce
the date information. Ideally no changes should take place to files after
you have pasted the date so that in the future, someone can look back at the
change.log and collections of files with timestamps and figure out which
files went into a release. In practice, you'll find that you need to check
in the change.log file, which messes this idea up slightly.
Commit the change.log file into svn. Example log message: "Documenting
1.64 changes."
- Run 'svn update' to make sure that all files in your working copy are from
the same svn revision. Note this revision number.
- Build for at least one platform, following the separate "Building EDEN..."
instructions. Make sure you don't have any special build environment set
up (eg a debugging build set up with [in bash] 'export CFLAGS=-O0').
- Check that what you have compiled works!
- Check that running the tool with the -v option gives the correct information:
ie the new version number and the associated svn revision. (Make sure it
is not a range of revisions, which may be if you ommitted the 'svn update'
step.)
- In {d}tkeden, check that Help->About and Help->ChangeLog give the correct
information.
- Record which svn revision was released as which EDEN version by making a
new "tag". Say the svn revision you noted a few steps ago (which should
also appear in the tool -v output) is 140 and the release number is 1.64.
Logged in as yourself, do (eg):
$ svn copy -r140 \
svn://emsvn.dcs.warwick.ac.uk/EDEN-recent/trunk \
svn://emsvn.dcs.warwick.ac.uk/EDEN-recent/tags/1.64 \
-m "Tagging EDEN release 1.64."
Installing a Linux release in ~empublic/bin:
- Note: this example is how to install ttyeden, tkeden and dtkeden version
1.64 from Ashley's Linux working copy.
ssh empublic@joshua
empublic@joshua$ cd ~/linux-i686/bin/
empublic@joshua$ scp -p \
ashley@joshua:workingcopies/EDEN-recent-linux/ttyeden ttyeden-1.64
(note: -p option to preserve file date+time,
copy to explicitly named version)
empublic@joshua$ scp -p \
ashley@joshua:workingcopies/EDEN-recent-linux/tkeden tkeden-1.64
empublic@joshua$ scp -p \
ashley@joshua:workingcopies/EDEN-recent-linux/dtkeden dtkeden-1.64
empublic@joshua$ chmod 755 ttyeden-1.64 tkeden-1.64 dtkeden-1.64
(executables need to be -rwxr-xr-x)
empublic@joshua$ cd ~/lib
empublic@joshua$ scp -pr \
ashley@joshua:workingcopies/EDEN-recent-linux/lib-tkeden lib-tkeden-1.64
(note: -p option to preserve file dates+times,
-r option to recursively copy the whole directory,
copy to explicitly named version)
empublic@joshua$ chmod 755 lib-tkeden-1.64
(lib directory needs to be -rwxr-xr-x)
empublic@joshua$ cd lib-tkeden-1.64
empublic@joshua$ rm -rf .svn
(svn creates a hidden directory which shouldn't go into the release)
empublic@joshua$ rm *~
(emacs creates backup files which need to be removed... basically
remove any unrequired stuff at this point)
empublic@joshua$ chmod 644 *
(library files need to be -rw-r--r--)
empublic@joshua$ cd ~/lib
empublic@joshua$ ln -s lib-tkeden-1.64 lib-ttyeden-1.64
(setup requires lib directory for each tool separately to make installation
flexible -- but no need to have three separate copies hanging around if
they are all the same, so use symlinks...)
empublic@joshua$ ln -s lib-tkeden-1.64 lib-dtkeden-1.64
empublic@joshua$ cd ~/bin
empublic@joshua$ ln -s eden.wrap ttyeden-1.64
empublic@joshua$ ln -s eden.wrap tkeden-1.64
empublic@joshua$ ln -s eden.wrap dtkeden-1.64
Now log out of empublic and test the installation logged in as you.
(You might need to say 'rehash' in some shells before they will see the
new executables in your PATH.)
(Make appropriate substitutions to the above instructions for making
a Solaris release.)
To change the default version that people get when running just (eg)
'tkeden' without a version number, edit ~empublic/bin/eden.wrap. You
will need to change the assignment to the VERSION variable in the 'case'
statement that follows the comment
# no version supplied: they want to run the most up to date stable version
Notes:
- RCS ("Revision Control System") is being used in the empublic installation
to keep track of changes to configuration files. Briefly, you need to
use (eg) 'co -l eden.wrap' to "check out" a file so that you can edit
it, and 'ci -u eden.wrap' to "check in" the file after your edit. To see
the history of a file, use (eg) 'rlog eden.wrap'. For more details, see
"man co", "man ci", "man rlog" and "man rcs".
- There is only rarely a need to change the default version right after
installing a new version. Let a few lucky (!) people know about the
new version first and get them to test it before inflicting it upon
everyone.
- Make sure to communicate the news about the change to the default version
to everyone that might be using it as soon as you change it, otherwise
people might get confused about what is happening. (Not everyone would
notice a version number change.)
Uploading a Windows / Mac OS X release to SiteBuilder:
- Go to
http://www2.warwick.ac.uk/fac/sci/dcs/research/em/software/eden/download/
- Press Edit button at the top right. (If this isn't visible: you need
to sign in and also have edit privileges on that page.)
- Choose "Upload & view files".
- Upload the file: make sure the filename is <=25 characters (required by
SiteBuilder) and follows the scheme of the filenames that are already there.
- In "Upload & view files", click the "Edit properties" button for your new
file (button with 4 coloured squares) and change the Sort order so that
the file appears in the correct place in the list. To get an idea of how
those numbers work, see
http://www2.warwick.ac.uk/fac/sci/dcs/research/em/
grouponly/website/downloadsordering/
- If you want to make the new file the default download, go to
http://www2.warwick.ac.uk/fac/sci/dcs/research/em/software/eden/
- Press Edit button at the top right.
- Choose "Edit raw HTML".
- Change the "a href" links for the appropriate download. You will need to
change the version number in three places (once for the icon link, once for
the filename link, and once for the filename).
Uploading a source release to SiteBuilder:
- Logged in as yourself, do (eg)
$ cd ~/exports
$ svn export \
svn://emsvn.dcs.warwick.ac.uk/EDEN-recent/tags/1.64 eden-source-1.64
$ cd eden-source-1.64
$ autoconf
(NB: ideally there would also be a 'make generate' step here, which
would avoid the need for people who download the source distribution
to have the right 'bison' installation. But 'make generate' requires
you to run './configure' first, and all this will create many other
things which perhaps shouldn't go into a release...
'make maintainerclean' should help with this, but it is a little
out of date...)
$ cd ~/exports
$ tar cvf eden-source-1.64.tar eden-source-1.64
$ gzip eden-source-1.64.tar
- Upload the resulting eden-source-1.64.tar.gz file to SiteBuilder, as per
the Windows / Mac OS X releases above.
