Please create gokey releases
bdrung opened this issue · comments
It would be nice to have proper releases. Otherwise I have to take git snapshots for the Debian package which leads to long versions like 0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-2.
So far the project is rather small with not too many commits. Also, the intent that it may be useful as a library (gokey cmdline being only one of the "frontends"). Given this and the way how people usually "import" go code with go get I would like to stick to the model "the master HEAD" is the current release.
Otherwise, with the current commit rate - every PR will just be a release on its own, which does not make much sense currently.
A release would be a sign for stability and a version schema like Semantic Versioning would show when an upgrade is backward compatible.
I don't think I can currently provide more guarantees than currently offered by the tests embedded. Moreover, as we saw in #17 there is more than the code version here. New releases of the Go language may break this package with not a single line changed. Stable in this sense would mean a specific commit here + a specific Go release. Without pinning to a Go release I would be misguiding the users about "stability" of the code.
But I don't want to take the responsibility on dictating people which Go version to install to compile this code. I encourage to always use the latest version as each Go release might have some security issues fixed.
I did some more thinking about it and because Go ecosystem moves towards "Go modules", which are based around semantic versioning I guess having release tags is desirable.
I tagged the latest master commit as v0.1.0 - did not use a 1.x major because there is still one TODO in the cmdline app.