antirez
Release version numbers
Would it be possible to have release numbers, this would make it easier for packaging Dump1090 into Debian for instance. It can be as simple as tagging the git repo with a version number... Thanks!
+1 for this. I'd like to package dump1090 for Nix/NixOS, and packaging "latest from git" feels a bit wrong. Just do a git tag -a -m "Version 1.0" v1.0 && git push --tags or something :-)
On Sun, Jun 09, 2013 at 02:17:10AM -0700, Emilien Klein wrote:
Would it be possible to have release numbers, this would make it easier for packaging Dump1090 into Debian for instance. It can be as simple as tagging the git repo with a version number... Thanks!
Agreed, but... you can give a version based the date of the last commit and maybe the initials of the repo owner for clarity.
I started to package for Debian a while back.... But right now the issue I would have... which stream to package? Or do we/you do multiple packages.
Recently I've been trying various heads and they all have advantages... and there is now a fairly large difference between some so its not simple to merge desirable features, nor have I time to do that integration work.
Good luck - if you want to share the packaging work, just shout! :)
@phedders: Sure, we already have some packages for projects with no releases, where we use git HEAD at packaging time and use the commit date as version. But I don't like it.
For example, if a repo has no releases, should all commits be considered stable, tested versions that should be shipped in downstream distros? And if the project is ready to be used by non-developers, why isn't there a release?
About the forks: I haven't looked at them closely. I want to package the "true upstream" one, and that seems to be this repo. I think packaging all the forks of this project would be the wrong way to provide all the features to users (i.e. having to install package "dump1090-feat123" for some features and "dump1090-feat456" for some other features feels weird). Rather, I hope that the forks at some point will be merged back into this repo. And if the result is considered "bloat", then provide compile time switches that removes some features to satisfy the people wanting it "non-bloated" :-)
On Mon, May 19, 2014 at 01:43:19PM -0700, Bjørn Forsman wrote:
@phedders: Sure, we already have some packages for projects with no releases, where we use git HEAD at packaging time and use the commit date as version. But I don't like it.
I see where you're coming from, and for large packages with complex dependancies and large user bases I would tend to agree.
For example, if a repo has no releases, should all commits be considered stable, tested versions that should be shipped in downstream distros? And if the project is ready to be used by non-developers, why isn't there a release?
Do there have to be "releases"? In an OS project with public repositories, all commits are releases since anyone can "download" that "release" and use/fork it.
I think its a bit easy to be trapped with the traditional model where someone did a whole bunch of work, and maybe collected a load of patches from others and periodically bundled it up and "released it to the masses". Proprietary SW still works that way, and I suggest that the "release" model isnt necessary or necessarily helpful for (at least) smaller and more independant code such as this.
With a project like this one, the tip of a master branch tends to be the one that is a good balance of up to date with fixes and features, where the features would hopefully have been developed and stabilised in "feature branches" already.
In practise doing disto releases from a recent commit is great - with git backporting fixes or select minor features is relatively easy and transparent
About the forks: I haven't looked at them closely. I want to package the "true upstream" one, and that seems to be this repo. I think packaging all the forks
A lot (majority?) of discussion in this thread has also referred to the MR fork and also BD extras to Malcomms work. This is the fork I am using most since it has a lot of extra features and better decoding in some areas.
So choosing a fork to package is a bit thorny!
of this project would be the wrong way to provide all the features to users (i.e. having to install package "dump1090-feat123" for some features and "dump1090-feat456" for some other features feels weird). Rather, I hope that
Exactly :)
the forks at some point will be merged back into this repo. And if the result
Ditto. But whether they are being pulled in orthogonal directions where mergining is either impractical or undesirable, I'm not sure. There was a certain amount of re-factoring that MR did meaning forks derrived from his fork are quite different to the "canonical" Antirez repo, and I'v no idea if there are plans to pull any of the substantial work in those forks back into Antirez's.
is considered "bloat", then provide compile time switches that removes some features to satisfy the people wanting it "non-bloated" :-)
Its tough having choice isnt it :)
Cheers!
On Mon, May 19, 2014 at 10:43:54PM +0100, Paul Hedderly wrote:
A lot (majority?) of discussion in this thread has also referred to the MR fork and also BD extras to Malcomms work. This is the fork I am using most since it has a lot of extra features and better decoding in some areas.
As if to make a point the last commit in Salvatore's repo commit 53cca39ed5da8e8aa33d6df975a0738cd1c9dc9b has this change to the README:
+While from time to time I still add / fix stuff in my fork, I target +minimalism of the implementation. However there is a +much more feature complete fork +available, developed by MalcolmRobb.
I am interested that he refers to it as his 'fork' since IIRC he wrote the original code and all other branches are forks... not his! But I think that shows his general very humlbe attitude to the code more than anything.
Regards
I'd agree not packaging all the forks, but only the "true" version, I have switched and tested this and Malcolm's fork, and the later gives no benefit, at least when feeding fr24, even using the built-in web interface, I still prefer Antirez's, much more "to hte point" Malcolm's is becoming overkill, when I ran his, I uses Antirez's gmap.html, much cleaner.
some people say Malcolm;s can be an inch better because it sends timestamps, my testing shows this to have no affect with fr24, perhaps it does on the other popular network, no idea, I settled on Antirez's original code for builds.
I agree with @Ressy66 and perhaps the only thing actually missing from @antirez's version is the --quiet flag (to be used in conjunction with --net).
@antirez: Any thoughts or comments on the possibility of a release / git tag?
