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

Support Go Modules not properly integrated #66

Closed
farrukhny opened this issue Jan 22, 2019 · 4 comments
Closed

Support Go Modules not properly integrated #66

farrukhny opened this issue Jan 22, 2019 · 4 comments

Comments

@farrukhny
Copy link

I think integration of go modules is good but i think it should not include version/release in path

module github.com/dimfeld/httptreemux/v5

Issues I have with that is all my code import path was based on github.com/dimfeld/httptreemux and i can used to just call httptreemux.NAME OF FUNC now i have to change all my import path for httptreemux by adding alias like

import httptreemux "github.com/dimfeld/httptreemux/v5"

also in case of creating new version/release you have to change path ?

please take a looks this example: https://github.com/lib/pq

@SamWhited
Copy link
Contributor

SamWhited commented Jan 22, 2019

I think it should not include version/release in path

If you don't do this for modules with a major version >1, module support will be broken.

Issues I have with that is all my code import path was based on github.com/dimfeld/httptreemux and i can used to just call httptreemux.NAME OF FUNC now i have to change all my import path for httptreemux by adding alias like

You can still do this; the /v5 is a virtual component of the path, the package name is still httptreemux, so that import you're using (import httptreemux "github.com/dimfeld/httptreemux/v5") isn't actually doing anything or renaming anything unless you're on an old version of Go that doesn't understand modules. (EDIT: actually, since httptreemux never imports within its own package tree, I don't think older versions will even see the /v5 since it only exists in the go.mod file, so nothing at all changes here).

All versions of Go from 1.9.7+, 1.10.3+, and higher major versions understand the /v5 in the import path, so if you're using a version of Go that's supported and receiving security updates (1.10 or 1.11) you should be fine.

also in case of creating new version/release you have to change path ?

Only on major version releases that break backwards compatibility, in which case having them have two different import lines means you can include both temporarily while you upgrade (eg. you can import /v5 in one place and /v6 in another).

please take a looks this example: https://github.com/lib/pq

That is still below version 2; you don't include the major version in the path for v1 modules.

If you're having some specific problem with this package, please post the error message and I'll be happy to assist you if it's a modules problem. Thanks!

@dimfeld
Copy link
Owner

dimfeld commented Jan 31, 2019

Thanks, Sam, for the detailed explanation. Unfortunately I can't reset to version 1 since that would break things for everyone else using an older version of the package with some other dependency manager. And even if I did, if I had to make a breaking change in the future, then the version suffix would come back again.

This is just how Go modules works, so I'll close this issue. On the bright side, this package is pretty much in maintenance mode, so breaking changes are pretty rare.

@dimfeld dimfeld closed this as completed Jan 31, 2019
@SamWhited
Copy link
Contributor

SamWhited commented Jan 31, 2019

I think you misunderstood, you don't have to reset to version 1, things will just keep working. Unless I'm misunderstanding something?

EDIT: nevermind, given that it's already on v5 I must have misunderstood and that was a reply to the OP.

@dimfeld
Copy link
Owner

dimfeld commented Jan 31, 2019

Yeah, I wrote it in a confusing way, but it was directed toward OP :)

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

No branches or pull requests

3 participants