mirror of
https://github.com/Hamlib/Hamlib.git
synced 2024-09-23 03:17:23 +00:00
0232e30fc0
Use the libtool link mode argument '-version-info' to set the Hamlib 3 ABI to be compatible with Hamlib 1.2 ABI. As the current ABI has not been changed or removed, we should be able to maintain backward compatibility. The libtool docs state that so long as the ABI is only added to, backward compatibility should be maintained. My idea here is to be able to have presently compiled programs be able to use binary libraries of Hamlib 3 without recompiling. So far I have tested this locally on Linux and Windows. More testing is welcome.
158 lines
5.9 KiB
Plaintext
158 lines
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
|
|
|