Thanks for your reply
On 26/01/2023 03:05, Dan Smith via chirp_devel wrote:
Since you're seeing py3dev I assume that means you're building directly from git? Why?
Because according to the README.md:
"This is the official git repository for the CHIRP project."
and it has recent commits.
I do releases, every day that there was a change.
I don't see any releases only daily builds which don't interest me from a packaging point of view.
I really wish you wouldn't randomly choose version numbers that don't match our automated releases > wasting your users time and ours when we try to figure out what
actual code someone is running when they report a bug. Also, we actually did have an 0.4.0, which was in 2014, so putting that in your version string is not helping anyone.
It was not chosen randomly. The last release in the "the official git repository" was 0.4.0 in 2014 so since then (I started maintaining the chirp package in 2014) I have used that as 'version' with a date string appended in the rel.
96% of the users run bundled builds, and a shockingly high percentage of those are running the latest version (as in from yesterday) when they report bugs.
If we receive a bug report about chirp which an update will fix then we will update the package, otherwise versions in stable distro releases are not randomly updated.
So by "I wish you did releases" I assume you mean "I wish you released features and fixes to the users less often to make my life easier", which I'm not interested in doing[1].
Not at all. I mean create a release with a proper PEP 440 type release number. If you saying that each 'daily build' is a 'release' and that the date string is the 'release number' then that is very unconventional but we could live with it if that is how it will remain.
Once we have a release number like 20230125 (over 20,000,000) there is no going back without an epoch! (Been there once already during the py3 transition)
I will look at a daily tarball.
Barry