This file is a release HOWTO, more or less a reminder before releasing
a new version of Hamlib.

TODO:   With the switch to Git SCM discuss the use of branches
        for releases and point releases.

Before deciding release:
-----------------------
* Anticipate what problems would users experience with the new release,
  so you can fix the problems before making the release.
  Basically, this is making sure the package will compile on a whole
  breed of systems (arch, OS, library, gcc, etc. combo),
  that there's no regression, and the API evolution is managed well.

* Announce version freeze on hamlib-developer mailing list,
  so developers have time to check in their contributions.
  In order to provide for a timely release schedule with the popular
  Ubuntu distribution, announcing a freeze around January 1 and July 1
  of each year will provide about a month of testing before release.

* Update the configuration:
    clean the tree (removing all files not tracked by Git):
        make dist clean; git clean -dxf

Releasing Hamlib:
----------------
In the master branch of your local repository (the key to working with Git
is that all work is committed to the local repository and then pushed to the
remote repository, "origin"):

* Assure the local repository is sync'ed with origin/master:
    git fetch
    git status

  At this point Git may produce a message such as:

  $ git status
  # On branch master
  # Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  #
  nothing to commit (working directory clean)

  As there appear to be no conflicts, the following command will sync your
  local repository to origin/master:

  $ git reset --hard origin/master
  HEAD is now at ??????? Last commit message summary

    Thanks, Kamal Mostafa, KA6MAL

* Update NEWS, TODO, AUTHORS

* Commit the changes to master:
  git status        # Assure that only the previous files are modified
  git commit -a     # Commit all modified files locally

* Create a new branch for the release:
  git branch Hamlib-3.1

* Push the changes (check for validity):
  git push origin       # pushes previous commit to sf.net repository
  git push -u origin Hamlib-3.1         # push the branch and set "upstream"

* Update the version in the macro AC_INIT of configure.ac (advance to next
  version, e.g. 3.1~git) and the ABI_RELEASE value in configure.ac.

  Note that -version-info is a libtool link mode argument and reflects ABI
  compatibility between Hamlib releases.  The values of ABI_VERSION,
  ABI_REVISION, and ABI_AGE are set in configure.ac. ABI_VERSION should be
  advanced when the ABI is affected by changes in the library interface.
  ABI_REVISION is the revision and indicates source changes in Hamlib but no
  change in ABI.  ABI_AGE reflects backward compatibility to a previous version.
  Per the libtool manual, this value is subtracted from ABI_VERSION to note
  compatible prior versions.  Per the libtool manual, so long as the library
  interface is added to and nothing is removed or changed, backward
  compatibility should exist.  When the API is changed, ABI_VERSION will be
  advanced, ABI_REVISION will be reset to 0, and ABI_AGE may be advanced
  pending API/ABI changes.

  Format is ABI version:revision:age.  Setting age to other than 0 causes
  strange DLL naming in Win32 cross-compile builds.

* Commit the changes to configure.ac and src/Makefile.am and push them to
  the remote repository.

At this point the master branch is ahead of the new release branch, however,
the version in the branch's version needs to have the "~git" changed to "~rc1"
which will be advanced for the next release candidate or stripped for final
release:

* Checkout the release branch:
  git checkout Hamlib-3.1

* Edit config.ac, commit it and push it.  The branch is now ready for
  rc testing/release.

* Build source tarball from a cleaned tree (as above):
    ./bootstrap
    ./configure
    make dist

    The resulting tarball--hamlib-3.y[.z].tar.gz--should be tested as much
    as possible to assure compilation integrity. etc.


Win32 binary build release
--------------------------

A new helper script is available in the scripts/ directory, build-win32.sh.
See README.build-win32 for information on prerequisites, etc.

* Build Windows DLL with cdecl convention using build-win32.sh

* Build Windows DLL with stdcall convention (script in progress):
  Ditto but with HAMLIB_API set to __stdcall in include/hamlib/rig_dll.h before re-compiling.
  Substitute cdecl by stdcall in README.txt.


* Release the file(s)
  - https://sourceforge.net/projects/hamlib/files/
  - Select Hamlib
  - Click Add Folder, name it X.Y[.Z]
  - Select X.Y[.Z]
  - Click Add File button
  - Click Choose File button
  - Click Upload
  - Click on (i) icon, select appropriate OS for "Default Download"

* Update http://www.hamlib.org Wiki
  - Download section
      https://sourceforge.net/apps/mediawiki/hamlib/index.php?title=Download

  - Documentation (requires doxygen)
      make -C doc doc
      ssh -t USER,hamlib@shell.sourceforge.net create
      mkdir /home/project-web/hamlib/htdocs/manuals/x-y-z
      scp -r doc/html/* USER,hamlib@shell.sourceforge.net:/home/project-web/hamlib/htdocs/manuals/x-y-z/.
      Edit Wiki Documentation section

  - Supported Radios/Rotators
      make -C tests rigmatrix.html
      ssh -t USER,hamlib@shell.sourceforge.net create
      scp -r tests/sup-info/* USER,hamlib@shell.sourceforge.net:/home/project-web/hamlib/htdocs/sup-info/.

* Notify various sites:
  - Sourceforge/News: https://sourceforge.net/news/submit.php?group_id=8305
  - Freshmeat: http://freshmeat.net/projects/hamlib
  - http://radio.linux.org.au/pkgdetail.phtml?pkgid=243 Linux Hamradio App: rigctl category

* Send announce to mailing lists: [ANN] hamlib-developer, linux-ham,
  debian-hams, fldigi-alpha, ham-linux

To advertise:
- list the rigs supported so far,
- what was major work achieved,
- where we're heading,
- what kind of support we need