xeipuuv / gojsonschema

An implementation of JSON Schema, draft v4 v6 & v7 - Go language
2.54k stars 355 forks source link

Please tag releases #112

Open onlyjob opened 8 years ago

onlyjob commented 8 years ago

Please consider assigning version numbers and tagging releases. Tags/releases are useful for downstream package maintainers (in Debian and other distributions) to export source tarballs, automatically track new releases and to declare dependencies between packages. Read more in the Debian Upstream Guide.

Versioning provides additional benefits to encourage vendoring of a particular (e.g. latest stable) release contrary to random unreleased snapshots.

Also compatibility with gopkg.in could be useful.

Thank you.

See also

ybbus commented 6 years ago

+1 @xeipuuv

qustavo commented 6 years ago

+1 @xeipuuv

qustavo commented 6 years ago

Specially now that dep and vgo are there

rostislav-rocket commented 6 years ago

Any update? Please tag this project

johandorland commented 6 years ago

To be honest I was a bit hesitant to start doing strict versioning as I'd rather spent my time on other things. However it does seem there are a couple of advantages tooling wise and it's not too much trouble, so I tagged a v1.0 release. Don't expect too much though in the future. This project is still fairly small so I won't be backporting bug fixes to multiple release branches, nor will there be any release schedule.

ashb commented 6 years ago

Sounds good - I at least was more after easier targets to put in my dep tooling rather than random commits. I am not expecting any back-porting of fixes, and agree that for small projects like this that a single branch and moving forward only is the way to go :)

plo- commented 5 years ago

To be honest I was a bit hesitant to start doing strict versioning as I'd rather spent my time on other things. However it does seem there are a couple of advantages tooling wise and it's not too much trouble, so I tagged a v1.0 release. Don't expect too much though in the future. This project is still fairly small so I won't be backporting bug fixes to multiple release branches, nor will there be any release schedule.

I understand well but it's true that strict versioning/tagging is really useful for tracking dependencies, for products and maintainers.

However it would have been better to use v1.0.0 instead of v1.0 as v1.0 is not SemVer compliant. SemVer is required for Go modules (https://github.com/golang/go/wiki/Modules#modules and https://github.com/golang/go/wiki/Modules#semantic-import-versioning) and as this repo does not have any valid SemVer tags, then its version is recorded with a "pseudo-version" such as v0.0.0-20181112162635-ac52e6811b56 which is hard to track :(

johandorland commented 5 years ago

My bad. I tagged a v1.1.0 release, so it should work now.

plo- commented 5 years ago

Perfect, it's ok. Thanks!