A stable project should have a Release Tag

[auyer]

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 ?

[vibridi]

Now that Go 1.13 is out, is there any news about this issue?

[vtolstov]

gentle ping, please tag v1.0.0

[FedeBev]

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.

[streadway]

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.