Hi!
today I discovered that the gr-osmosdr package in debian unstable contains a whooping list of 96 patches. This is due to the fact that since November 2014 there hasn't been any tagged versions in the repository.
I'd like to suggest to tag releases a bit more often.
@horizon: What about jumping to 1.0.0 right away?
Regards, Harald
On Sun, 3 Jun 2018 20:17:31 +0200 Harald Welte laforge@gnumonks.org wrote:
Hi!
today I discovered that the gr-osmosdr package in debian unstable contains a whooping list of 96 patches. This is due to the fact that since November 2014 there hasn't been any tagged versions in the repository.
98. But I do not apply 0001-update-version-to-0.1.5git.patch so that the version stayed at 0.1.4.
I added Alex Csete's patch Add-initial-support-for-Airspy-HF from his fork of gr-osmosdr for gqrx.
And a trivial doxygen-reproducible patch that should make the reproducible-build folk happy.
Please consider incorporating those before your next release tag.
I'd like to suggest to tag releases a bit more often.
Let me second that! Release Early, Release Often!
Bonus points for cryptographic signing or released source, either by using gpg with git to sign tags, or creating detached signatures of release source tarballs.
@horizon: What about jumping to 1.0.0 right away?
Regards, Harald
0.1.5 would still work fine. Due to steady C++ compiler changes and my aggressive bumping of gnuradio's soname and soversion for each gnuradio release, I have not been so worried about checking API and ABI changes with gr-osmosdr. Package dependencies make upgrades work smoothly.
Some more details about Debian packages that may interest this list: As described in debian/copyright, in lieu of gr-osmosdr release tarballs, I use git archive --format=tar --prefix=gr-osmosdr-0.1.4/ v0.1.4 \ | xz > ../gr-osmosdr_0.1.4.orig.tar.xz to create the basis of the Debian source package.
Then, to get more of your recent good work out of your git tree and into Debian packages, I use git format-patch v0.1.4 to generate a series that gets applied to the source tarball via Debian quilt patch format source packaging tools.
But yes, that begins to get annoying with so many commits between tags.
Thanks for all your good work on making gr-osmosdr so useable and useful!
Your humble Debian package maintainer, -Maitland
P.S. If you contribute to osmocom, some of my remarks I made at the last gnuradio conference, grcon17, apply to you too: https://www.youtube.com/watch?v=yKKjbT6YXgA
Thanks again for all the good bits.
Hi, Could you even add my patches for Persues receiver as found in
https://github.com/IW0HDV/gr-osmosdr/tree/perseusairspyhf
?
Andrea Montefusco IW0HDV
On 3 June 2018 at 21:54, A. Maitland Bottoms bottoms@debian.org wrote:
[...] Then, to get more of your recent good work out of your git tree and into Debian packages, I use git format-patch v0.1.4 to generate a series that gets applied to the source tarball via Debian quilt patch format source packaging tools.
In Nixpkgs we ship plain v0.1.4, because that is the latest release. If you (gr-osmosdr developers) want users to get newer software, please make a tag / release.
- Bjørn Forsman
A. Maitland Bottoms 2018-06-03 21:54:
On Sun, 3 Jun 2018 20:17:31 +0200 Harald Welte laforge@gnumonks.org wrote:
today I discovered that the gr-osmosdr package in debian unstable contains a whooping list of 96 patches. This is due to the fact that since November 2014 there hasn't been any tagged versions in the repository.
But I do not apply 0001-update-version-to-0.1.5git.patch so that the version stayed at 0.1.4.
I added Alex Csete's patch Add-initial-support-for-Airspy-HF from his fork of gr-osmosdr for gqrx.
And a trivial doxygen-reproducible patch that should make the reproducible-build folk happy.
Please consider incorporating those before your next release tag.
I'd like to suggest to tag releases a bit more often.
@horizon: What about jumping to 1.0.0 right away?
0.1.5 would still work fine.
What do you think of Semantic Versioning (https://semver.org/)?
Summary
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
FAQ
[...] How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0. [...]
gr-osmosdr being actively used for years now and already including dozens of patches and forked-tree features, it seems to me that 1.0.0 is completely warranted. If bugfixes and new features keep on coming, bumps in minor number and patch number seem to help make versions better comparable.
BR
Patrick
Dear Dimitri and Steve,
On Sun, Jun 03, 2018 at 08:17:31PM +0200, Harald Welte wrote:
today I discovered that the gr-osmosdr package in debian unstable contains a whooping list of 96 patches. This is due to the fact that since November 2014 there hasn't been any tagged versions in the repository.
I'd like to suggest to tag releases a bit more often.
@horizon: What about jumping to 1.0.0 right away?
is there anything we can do about the status/progress of gr-osmosdr, particularly in terms of tagging new releases?
I understand that people do have a life and other priorities, and that those priorities change.
But the fact that there's a Osmocom sub-project which is heavily used by people out there, and which is packaged by distributions yet we don't tag any releases for more than four years is also problematic.
What can I do (or anyone else do) to change this? Sure, I could just push a tag to the repository, but I'm not a developer of gr-osmosdr and hence I feel neither qualified nor have any authority.
Thanks for your time and help!
Regards, Harald