Hi everyone, hi especially Steve, I'm in the process of making a distro package for fl2k for sharing and inclusion in my bootable Fedora sticks; as a version, I'd use 0.0.0.1- githash, but I think that's an understatement, because it looks to me like fl2k was officially released at OsmoCon. Now, I'm not the author, and I'd hate to be the one to define today's git head as version 1, or something like that, but I honestly think that it's worth encouraging tagging of a release (as it would make it easy to refer to things like "hey, that used to work with 1.0.2.1, but broke in 1.0.3.1", or include it with other software etc). Would it be very annoying to kindly request that you add a version tag, and to even brazenly recommend semver.org as versioning scheme? Thanks, and I'm having great fun with this, Marcus
I've decided to go with a package version of 0.0.0.0_DATEgitSHORTHASH so as to avoid conflict with whatever you decide to come up with (which really, really is your business). And whoever would like Fedora 26,27,28,rawhide packages (my CentOS/RedHat/EPEL 7 build broke because things): https://copr.fedorainfracloud.org/coprs/marcusmueller/osmo-fl2k/ Note that I'm not trying to be "official upstream", so as usual, please make sure this package contains what you really want. For now, it seems to do what is needed to make fl2k_test etc. work, and installs the library as well as the udev rules that make the dongle belong to group "fl2k". Maybe I should be splitting things into libfl2k and fl2k-utils and fl2k-filesystem or something to separate libs, executables and udev rules. Best regards, Marcus On Fri, 2018-04-27 at 11:34 +0000, Müller, Marcus (CEL) wrote:
Hi everyone, hi especially Steve,
I'm in the process of making a distro package for fl2k for sharing and inclusion in my bootable Fedora sticks; as a version, I'd use 0.0.0.1- githash, but I think that's an understatement, because it looks to me like fl2k was officially released at OsmoCon.
Now, I'm not the author, and I'd hate to be the one to define today's git head as version 1, or something like that, but I honestly think that it's worth encouraging tagging of a release (as it would make it easy to refer to things like "hey, that used to work with 1.0.2.1, but broke in 1.0.3.1", or include it with other software etc).
Would it be very annoying to kindly request that you add a version tag, and to even brazenly recommend semver.org as versioning scheme?
Thanks, and I'm having great fun with this,
Marcus
On Fri, Apr 27, 2018 at 02:31:23PM +0000, Müller, Marcus (CEL) wrote:
I've decided to go with a package version of 0.0.0.0_DATEgitSHORTHASH so as to avoid conflict with whatever you decide to come up with (which really, really is your business).
FYI: Debian went for "0.1.0+20180423git9e79bde" as can be seen at https://packages.debian.org/sid/osmo-fl2k I agree that at least some initial version talk should be put into the osmo-fl2k repository. But that's of course up to steve-m. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Marcus, On 27.04.2018 13:34, Müller, Marcus (CEL) wrote:
Now, I'm not the author, and I'd hate to be the one to define today's git head as version 1, or something like that, but I honestly think that it's worth encouraging tagging of a release (as it would make it easy to refer to things like "hey, that used to work with 1.0.2.1, but broke in 1.0.3.1", or include it with other software etc).
Would it be very annoying to kindly request that you add a version tag, and to even brazenly recommend semver.org as versioning scheme?
Actually the cmake Version module was already in place and set to version 0.1git - it just didn't work properly because an initial tag was missing. As Debian and SuSe already used 0.1.0 as version, I've now tagged a 0.1.1 release and advanced to 0.1git again. The version module now seems to work as expected, I now get "Version: v0.1.1-1-g2ff7". Best Regards, Steve
Hi Steve, oh, I've been missing that :) will advance the git commit pointer, and fix versioning tomorrow. Thanks for all the cool work! Best regards, Marcus On Sat, 2018-04-28 at 22:29 +0200, Steve Markgraf wrote:
Hi Marcus,
On 27.04.2018 13:34, Müller, Marcus (CEL) wrote:
Now, I'm not the author, and I'd hate to be the one to define today's git head as version 1, or something like that, but I honestly think that it's worth encouraging tagging of a release (as it would make it easy to refer to things like "hey, that used to work with 1.0.2.1, but broke in 1.0.3.1", or include it with other software etc).
Would it be very annoying to kindly request that you add a version tag, and to even brazenly recommend semver.org as versioning scheme?
Actually the cmake Version module was already in place and set to version 0.1git - it just didn't work properly because an initial tag was missing. As Debian and SuSe already used 0.1.0 as version, I've now tagged a 0.1.1 release and advanced to 0.1git again. The version module now seems to work as expected, I now get "Version: v0.1.1-1-g2ff7".
Best Regards, Steve
participants (3)
-
Harald Welte -
Müller, Marcus (CEL) -
Steve Markgraf