Coronavirus (Covid-19): Latest updates and information
Skip to main content Skip to navigation

Making a release

- 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.