rtl_433 needs a version number

[matthewwall]

please implement a version number for rtl_433, accessible like this:

rtl_433 --version

then do tagged releases with the version number.

we're starting to get some rtl_433 users with the weewx-sdr driver, and without a version number it is really difficult to know what rtl_433 they're using (the commit hash from git is only marginally helpful - many of these people are not using git to get rtl_433)

i know it is difficult to do versioning when you have so many contributors from so many plugins, but i'm sure you can come up with something that will alleviate the support issues without being too cumbersome to the development process.

[merbanan]

I can do 2-4 yearly releases, would that be fine ?

[matthewwall]

that would help a lot. could rtl_433 spit out its version (and perhaps the git hash if it is not a tagged release?) as part of the startup output or when --version is specified?

(i'm not a fan of the way svn may modify files when you commit, but the $Revision$ tag was very useful for this purpose)

[Romeo-Golf]

+1 for version number and stable releases, even if infrequent they provide much needed basis for other projects to check that the installed version is recent enough for any feature or device support they require.

[ZeroChaos-]

bump, same request :-)

[DL4APT]

I tried to make an test release with an included windows build. windows build is working fine at the moment I don't have an running Linux to make an test builds. https://github.com/DL4APT/rtl_433/releases

[TimelessNL]

Yeah it would be nice to have a version number, also regular releases are appreciated.

[zuckschwerdt]

Semantic Versioning comes to mind. But for an application it is not as impactful as for libraries.
What is the primary concern in version numbers here?
The user should be supplied with a clear indicator how stable (a) and recent (b) a version is and how many features (c) or incompatibilities (d) an update will bring. A version scheme meant primarily for humans to understand.
There will be just a single head version (no LTS or "stable" line) for quite some time.
Maybe adopt some form of Calendar Versioning for (a) and (b) with a solid Changelog for (c) and (d).
Otherwise perhaps a major.minor scheme for (d) and (c) -- I'm afraid that major will be stuck and minor a runaway number without too much value then.
Input on a policy is very much welcome, I'd like to implement something in 1-2 weeks.

[merbanan]

Feel free to implement that. My opinion is that significant new functionality and command line api changes warrant a new version number.

[rct]

In terms of use case, my assumption is most users of rtl_433 use some sort of consumer that parses the output of rtl_433. If changes in rtl_433 are going to require changes in their downsteam code, there should be a reasonable way of referring to the versions before and after the change. So an author of some other piece of software should be able to say tested/works with rtl_433 X.Y.Z, or the 2018-02 release or something like that.

Unfortunately there currently isn't a good notion for which decoders are considered stable vs. experimental. Some decoders, like car keys, may always be experimental. Others like weather stations, environmental monitors, security sensors, would ideally reach a stable state, and if it has to change, there should be some version change to indicate that the release is no longer compatible for some decoders.

[rct]

I haven't looked at rtl_433_tests in a while. but maybe the saved json in there could be used an an indication of stability and whether a new version should be considered incompatible with prior versions.

[zuckschwerdt]

Yes, stability of the output format can't be guaranteed forever but should at least come with a warning (Changelog) and not change at arbitrary points.
I've expanded rtl_433_tests with more output snapshots and I'm using it to check exactly that. But quite some samples and expected outputs are still missing or in bad shape.

[merbanan]

@zuckschwerdt can you tag a 18.12 version when you feel it is appropriate and then close this issue?

[merbanan]

Closing issue, the devs will tag a release soonish.