Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add go.mod in order to allow semantic import versioning #193

Closed
wants to merge 1 commit into from

Conversation

m90
Copy link
Contributor

@m90 m90 commented Aug 26, 2018

As the latest version is tagged as v4.x.x in git, using the package as a Go module will require importing it as github.com/go-telegram-bot-api/telegram-bot-api/v4, otherwise it will show up as:

github.com/go-telegram-bot-api/telegram-bot-api v4.6.2+incompatible
in a dependent's go.mod.

See: https://github.com/golang/go/wiki/Modules#semantic-import-versioning

@m90
Copy link
Contributor Author

m90 commented Aug 26, 2018

Looks like this is not what should be done right now: golang/go#25967 (comment)

@m90 m90 closed this Aug 26, 2018
@thepudds
Copy link

@m90 one quick comment: it looks like this package has been using gopkg.in as the standard import path for consumers?

If that is the case, then the whole complexity of semantic import versioning for v2+ Go modules is really side-stepped, because Go modules keep an import like import "gopkg.in/telegram-bot-api.v4" working just as it always has, and there is no requirement to change import paths from a working gopkg.in/telegram-bot-api.v4 if the project opts in to Go modules.

From the doc:
https://tip.golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning

As a special case, module paths beginning with gopkg.in/ continue to use the conventions established on that system: the major version is always present, and it is preceded by a dot instead of a slash: gopkg.in/yaml.v1 and gopkg.in/yaml.v2, not gopkg.in/yaml and gopkg.in/yaml/v2.

One way to look at it is this project already opted in to having the major version in its import paths by virtue of using gopkg.in, and Go modules know how to understand that properly (and of course older Go versions like 1.8, 1.9, 1.10 continue to work with gopkg.in just like they always have).

Opt-ing in to Go modules is reasonably straightforward for a v0 or v1 project, and it should be more-or-less just as straightforward to opt-in to Go modules for a v2+ project that was already publishing itself via gopkg.in...

All that said, Go modules are 100% opt-in at this point, so makes sense to do whatever works best for your project.

CC @myitcv in case he has any additional comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants