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.
|
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. |
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.