Making a release about cnping HOT 9 CLOSED

@cnlohr good to hear from you again!

For formal instructions to versioning, most people refer to semver, but actually I believe for this kind of software (not a library, not really expected to be called from scripts...) the real point of having versions is that humans are better in comparing and remembering them than doing it all with dates or even git hashes. (Dates are also problematic in the rare case of releasing two bug fixes in one day...)

I don't know whether the current changes need some time for testing but maybe we can just call this 1.0.0 and go from there. (Note that most people prefix the git tag with v, e.g. "v1.0.0")

from cnping.

See void-linux/void-packages#13627

from cnping.

@jcgruenhage @dreua I am a-ok with this. I've never implemented versioning for that sort of thing. What kinds of steps would we use to do a versioning scheme? I am back to doing some github stuff after working insane hours at my new job for about 8 months.

from cnping.

The most basic thing would be to just declare this as version x.y.z and add a tag to the git repository. If you want something more, you can also integrate the version into the source, so that cnping --version or something like that can print the current version. There is not much more to it than that.

from cnping.

Should we push for 1.0-pre then? And have you guys test it?

from cnping.

In my testing, cnping has worked flawlessly. I;d be happy to see this declared as 1.0, anyone else (especially @cnlohr) got an opinion on that? A non-pre release is a blocker at least for the voidlinux package

from cnping.

I would prefer 1.0.0 to be more in line with semver. No other objections.

from cnping.

I can integrate Travis ci and release 1.0.0 after work, i.e. in about 10 hours.

from cnping.

1.0.0 is out, let me know if there is anything else.

from cnping.