-
Notifications
You must be signed in to change notification settings - Fork 108
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
unify import paths under /v4 #62
Conversation
Create a new /v4 directory, containing a copy of the existing code, allowing the package to move forward and be consumed by all users under a unified import path: github.com/gofrs/uuid/v4. Remove go.mod file from the top level directory and add it to the v4 directory. Update v3 to v4 in go.mod. Update documentation to reflect the change: Recommend v4.0.0+ as the go-to version for new users and existing modules users. Recommend v2.1.0 under github.com/gofrs/uuid as the go-to version for users looking for a replacement for satori/go.uuid at v1.2.0. Document the two different import paths and their behavior. Fixes #61.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, no.
You're welcome to try to talk the actual users out of it in #61, then. |
Could we use a symlink? |
@jadr2ddude on windows git would not create a symlink |
Ok. Ugh. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like Git on windows supports symlinks now, but perhaps only for newer versions? Can we try? I don't have a Windows machine handy this week.
Can you be more specific about what it is you are objecting to here? @acln0 has, to my mind, taken the right step of distilling a concrete straw-man PR out of the advice from @bcmills and @thepudds in #61. Constructive comments on where that straw-man deviates from the advice would probably be more useful. Else, if it's the advice you disagree with, I'd suggest we continue the discussion in #61. |
In #61, @bcmills describes one possible solution to the current import path conundrum: > Hmm, come to think of it, you might not even need to switch to major > version 4. You could make v3.2.0 a forwarding package (without a > go.mod) to github.com/gofrs/uuid/v3), with a corresponding v3.3.0 > (with a go.mod) that provides the /v3 module. This patch is a demo of the first phase of this solution. It removes the go.mod file, moves existing code to the new /v3 subdirectory, and adds a forward.go file in the root directory, with forwarding declarations and type aliases, targetting /v3. For discussion and comparison with the approach in #62.
@myitcv I believe in "A little copying is better than a little dependency", but I'm adamantly against versioned subdirectories and the subsequent code copying. I want to make use of the repository's metadata for version information and not directory structure. |
Did you see #61 (comment) which confirms:
|
Abandoning in favor of #66. |
Create a new /v4 directory, containing a copy of the existing code,
allowing the package to move forward and be consumed by all users
under a unified import path: github.com/gofrs/uuid/v4.
Remove go.mod file from the top level directory and add it to the v4
directory. Update v3 to v4 in go.mod.
Update documentation to reflect the change: Recommend v4.0.0+ as the
go-to version for new users and existing modules users. Recommend
v2.1.0 under github.com/gofrs/uuid as the go-to version for users
looking for a replacement for satori/go.uuid at v1.2.0. Document the
two different import paths and their behavior.
Fixes #61.