This has been discussed in #125, #280 and #312, but there are a few new things to consider.
In 2017 @michaelklishin said :
Maybe once Go adopts an official package management tool, this can be revisited.
It is not default yet, but it exists.
Go Modules is a thing since GO1.11, and although it is still being discussed, the semantic versioning is a key part to make it more viable, just like it is key for every other package manager out there.
Without it, a mod file looks like this:
module amqp/client
go 1.12
require (
github.com/google/uuid v1.1.1
github.com/streadway/amqp v0.0.0-20190404075320-75d898a42a94
)
Even without modules, release tags can be used by tools like gopkg.in to have imports like gopkg.in/yaml.v1
This is not only helpful, but also a good practice. This project is stable, but repositories without 1.x release tags are usually considered unstable.
Shall we discuss some more ?
Now that Go 1.13 is out, is there any news about this issue?
gentle ping, please tag v1.0.0
I really can't understad why this project is still unversioned and actually I totally agree with @auyer.
In 2017 there was a valid reason, but now I don't think so. Amqp is potentially a very important dependency of a project, so is very important to have a stable ad human-usable versioning.
Please, deal with this.
The reason for not tagging is I've been strict with maintaining backwards compatibility. So every change would effectively be a patch release which is no different than a go.mod timestamp. I also believe we should be continuously integrating, even at OSS scale and wanted to promote that by developing on a single release timeline.
I hope nobody using this package every had the need to pin a dependencies to an older version.
@auyer I'm glad you brought up the topic of viewing the resolved dependency graph and having a v0.0.0 stand out as an integration against pre-release. This is a good argument for tagging.
@vibridi @vtolstov Thanks for the reminders - sorry they went unanswered.
@FedeBev When making future issues, would you please present a concrete case that you would benefit from and use a less-demanding tone in your language.
Most helpful comment
The reason for not tagging is I've been strict with maintaining backwards compatibility. So every change would effectively be a patch release which is no different than a go.mod timestamp. I also believe we should be continuously integrating, even at OSS scale and wanted to promote that by developing on a single release timeline.
I hope nobody using this package every had the need to pin a dependencies to an older version.
@auyer I'm glad you brought up the topic of viewing the resolved dependency graph and having a v0.0.0 stand out as an integration against pre-release. This is a good argument for tagging.
@vibridi @vtolstov Thanks for the reminders - sorry they went unanswered.
@FedeBev When making future issues, would you please present a concrete case that you would benefit from and use a less-demanding tone in your language.