This is a cookbook showing the steps required to create a libLASi release at
SourceForge.

* set environment variables (used extensively below) for versions

export LASI_VERSION=1.1.0
export TAG_VERSION=v1_1_0

* Prepare a preliminary version of the ChangeLog file to see what has been
  accomplished since the last release.

svn log --verbose > ChangeLog.preliminary

* Update and commit the README.release file with a short overview of the
  specific changes noted in the ChangeLog since the last release.

* Update and commit cmake/module/lasi_version.cmake to reflect the current
  version. Also, follow the instructions in this file for updating the
  SOVERSION, the minor number and the patch number.

* Make a preliminary version of the source release tarball. (If starting
  from scratch do the usual build up to and including the "make" command to
  build the documentation in the source tree.) Then make the source
  distribution tarball (in the top of the build tree) with

make package_source >& make_package_source.out

* Check the generated tarball by checking its table of contents, unpacking
  it, and building and testing (ctest and install tree test of examples)
  libLASi from it.

* Make sure your local version of libLASi is synched with the SourceForge
  one.

svn update
svn status

* Create final version of complete ChangeLog and commit it.

svn log --verbose > ChangeLog
svn commit ChangeLog
svn update

* Create a server-side tag corresponding to the release version to provide
  a historical record (snapshot) of the trunk at the time of the release.

svn copy \
https://lasi.svn.sourceforge.net/svnroot/lasi/trunk \
https://lasi.svn.sourceforge.net/svnroot/lasi/tags/$TAG_VERSION

  In the event that problems are found in libLASi during the release
  process, corrections should be made to trunk/ and then merged into the
  tags/vX_Y_Z branch as follows:

cd tags/vX_Y_Z
svn merge -r A:B /path/to/trunk

  Where A and B specify the range of revisions in trunk to be applied to
  tags/vX_Y_Z in the merge process. These can be determined by commit
  messages.

  N.B. the above directions have been copied from PLplot, but I have not had
  an opportunity to try such a merge yet so check the svn manual if you
  actually do need to do this.

* Check out the tagged version into a new directory

svn checkout \
https://lasi.svn.sourceforge.net/svnroot/lasi/tags/$TAG_VERSION
lasi_tagged

* Test that tagged version by building and ctest and installed examples test.

* Create the release tarball from the tagged version following above tarball
  creation and testing steps.

* Create an md5sum for the tarball so that users can check their downloads
  for problems.
  
md5sum lasi-$LASI_VERSION.tar.gz > lasi-$LASI_VERSION.tar.gz.md5

Edit a local /tmp/ChangeLog.release (not under svn control) to be the
appropriate date range from ChangeLog (i.e. only the changes that were made
since the last release should be included).  Also copy README.release to
/tmp as a matter of convenience.  These /tmp files will be uploaded to
SourceForge later.

Upload the libLASi-$LASI_VERSION.tar.gz.* files to the SF upload section

ftp upload.sourceforge.net #username is ftp, password is your e-mail address
cd incoming
bin
put libLASi-X.Y.Z.tar.gz
put libLASi-X.Y.Z.tar.gz.md5
quit

  N.B. X.Y.Z used rather that $LASI_VERSION because ftp command mode
  does not understand enviroment variables.

* Prepare a file release at SourceForge using their GUI Tool:

Login to sf.net.
Go to the libLASi project page.
Select file releases in the drop down admin menu at the top of the page.
Click add release at the bottom of the page.
Enter the new release name and click "create this release".

  N.B. Release names guide our users to the release they want when they
  browse our file release area.  The source release names should be of the
  form "X.Y.Z Source" (e.g., "1.1.0 Source").  The reason for this
  suggestion is to keep source release names distinct from binary release
  names.

In the file release GUI (Step1):
Browse to /tmp/README.release in "Upload Release Notes".
Browse to /tmp/ChangeLog.release in "Upload Change Log".
Select "preserve my pre-formatted text"
Click "Submit/Refresh"

In the file release GUI (Step2):
Select (and only select) the uploaded libLASi files.
Click "Add Files and/or Refresh View"

In the edit file in release GUI (Step3):
For libLASi-X.Y.Z.tar.gz select "any" for the processor type and "source.gz" for
the file type.
For libLASi-X.Y.Z.tar.gz.md5 select "any" for the processor type and
"other source" for the file type.

In the e-mail notification GUI (Step4):
Select that you are sure that you want to send an e-mail to those who are
monitoring the libLASi releases (once some SourceForge users sign up
for this).

Prepare the release notes (taken mostly from README.release):
Return the libLASi project page
Select Admin -> News
Click on submit to create a new news item.
Load an old release news item in another browser window and use that as a 
template for creating your new release news item. Make sure that you get
the link to the release notes correct (none of the other links need to be
changed).
Click on submit.

Download libLASi-X.Y.Z.tar.gz* from SourceForge and make sure those files
are identical with the uploaded versions.

Publicize release on lasi-devel mailing list.

Publicize release at www.unifont.org/lasi.

(Optional) publicize wherever software announcements are still accepted for
free software (lwn.net, lxer.com, freshmeat.net, etc.). 

DONE!!!
