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

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

Closed
hsluoyz opened this issue Jun 3, 2020 · 13 comments

Comments

@hsluoyz
Copy link

@hsluoyz hsluoyz commented Jun 3, 2020

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
Copy link

@nodece nodece commented Jun 3, 2020

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
Copy link
Contributor

@xhit xhit commented Jun 3, 2020

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
Copy link

@nodece nodece commented Jun 3, 2020

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
Copy link
Member

@mvdan mvdan commented Jun 3, 2020

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
Copy link

@nodece nodece commented Jun 3, 2020

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
Copy link
Contributor

@xhit xhit commented Jun 3, 2020

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 hsluoyz changed the title How to avoid the import path update disaster when upgrading major versions? How to avoid changing import paths for all source code files when upgrading major versions? Jun 3, 2020
@hsluoyz
Copy link
Author

@hsluoyz hsluoyz commented Jun 3, 2020

@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
Copy link
Contributor

@toothrot toothrot commented Jun 8, 2020

@hsluoyz Does #38762 address your concerns?

@nodece
Copy link

@nodece nodece commented Jun 9, 2020

@toothrot It seems to meet our expect.

@nodece
Copy link

@nodece nodece commented Jun 9, 2020

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
Copy link
Contributor

@toothrot toothrot commented Jun 12, 2020

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
Copy link

@nodece nodece commented Jun 13, 2020

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
Copy link
Member

@andybons andybons commented Jun 15, 2020

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:

Please ask the question on one of the above forums.

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

@andybons andybons closed this Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.