How to avoid changing import paths for all source code files when upgrading major versions?

[hsluoyz]

In our code, we start to use Go modules for v2. Then we had a breaking change (casbin/casbin#472 (comment)) and based on Semver, we need to bump to v3. But this requires all our source code files to update all import paths from v2 to v3. And it also requires all our users' code that imports our library to change their import paths from v2 to v3. This is very inconvenient. And our users are not happy: casbin/casbin#478 (comment) It not only requires a lot of work for each major release, but also makes the git history looking bad.

For other package managers like npm (node.js) or pip (python), it just needs to update the version in the dependency file, no need to update source code.

Can we have a good solution to avoid changing import paths for all source code files for major version releases?

[nodece]

Expect

casbin go.mod

module github.com/casbin/casbin

Let's say v10.0.0 has been released in GitHub.

Developer can get the dependency by go get github.com/casbin/casbin@v10 and import it into own project by import "github.com/casbin/casbin.

[xhit]

Expect

casbin go.mod

module github.com/casbin/casbin

Let's say v10.0.0 has been released in GitHub.

Developer can get the dependency by go get github.com/casbin/casbin@v10 and import it into own project by import "github.com/casbin/casbin.

What about large projects that use various versions of a package?

Some packages break compatibility but instead migrate to newer version instantly we import both modules with different versions and add a notice to users that function is deprecated and will be dropped in X versions of the program.

This is why we use the import with vX suffix in the source code, this allows to use two or more versions, example:

import casbinV1 "github.com/casbin/casbin when v1
import casbinV2 "github.com/casbin/casbin/v2 when v2

And go.mod:

require (
    github.com/casbin/casbin v1.0.1
    github.com/casbin/casbin/v2 v2.0.5
)

Take this into account before make a proposal.

[nodece]

Why we doesn't consider using github.com/casbin/casbin replace version with vX suffix and support multiple versions?

go.mod:

require (
    github.com/casbin/casbin v2.0.5
    // github.com/casbin/casbin v1.0.0  
    github.com/casbin/casbin/v2 v2.0.5
    github.com/casbin/casbin/v3 v3.0.0
)

[mvdan]

There have been other issues on this topic before; have you tried searching?

I would also suggest avoiding dramatic words like "disaster" when filing issues, so that we can just focus on the topic at hand.

[nodece]

Relate issues: #32014, #32816

There is a lot of work to do from vX to v(X+1), so I have a bit puzzle, how to update dependency paths when major releases are released :(

[xhit]

Also #25518 is related.

Personally automates the version bump can be a nightmare. Not all developers breaks the compatibility, some deprecate functions before make code obsolete.

[hsluoyz]

@mvdan sorry, I have fixed my wording. Like @nodece @xhit said, I also noticed those issues but didn't get a very clear solution for it. Any advice? Or will Go fix this issue in future?

[toothrot]

@hsluoyz Does #38762 address your concerns?

[nodece]

@toothrot It seems to meet our expect.

[nodece]

I would like to present my ideas here on how to install dependency of different version here.

Let's assume there are multiple versions like v1, v2, module is github.com/nodece/casbin.

Expect

things1

If the user does not install this dependency, you can get the latest version of v2 by go get github.com/nodece/casbin and import it by github.com/nodece/casbin, but it gets v1 version now :(

I hope that get the dependency by go get github.com/nodece/casbin then convert module to github.com/nodece/casbin.

things2

How resolve the import with vX suffix in the source code, example:

import casbinV1 "github.com/nodece/casbin when v1
import casbinV2 "github.com/nodece/casbin/v2 when v2

I hope that the get the dependency by go get github.com/nodece/casbin@v2 then convert module to github.com/nodece/casbin/v2.

I hope that the get the dependency by go get github.com/nodece/casbin@commit_id then convert module to github.com/nodece/casbin.

[toothrot]

I'm not sure I understand. Do you mean that the package import path (in .go files import statements), the URL, and the module URL should refer to different packages?

One of the primary design goals of modules is that different major versions are different packages to add clarity around breaking API changes.

[nodece]

One of the primary design goals of modules is that different major versions are different packages to add clarity around breaking API changes.

I see, but we need to update import path (in .go files import statements) when major version has been release.

It looks unfriendly :(

[andybons]

Hi there,

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For asking questions, see:

• Stack Overflow with questions tagged "go"

• The Go Forum, a web-based forum

• Gophers Slack, use the invite app for access. The #general channel is a good starting point.

• Go Community on Hashnode with questions and posts tagged with "go"

• The golang-nuts mailing list

• IRC channel #go-nuts on Freenode

Please ask the question on one of the above forums.

(Quoted from https://golang.org/wiki/Questions)