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