Hamlib/README.release

158 wiersze
5.9 KiB
Plaintext

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 compatibity 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
compatibity 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):
./autogen.sh
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.
Subsitute 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