The latest commit (move stuff to v2) breaks package with go 1.10 and earlier

[laurikoobas]

Everything is in the name.

go get github.com/pierrec/lz4

package github.com/pierrec/lz4/v2/internal/xxh32: cannot find package "github.com/pierrec/lz4/v2/internal/xxh32" in any of:
        /usr/lib/go-1.9/src/github.com/pierrec/lz4/v2/internal/xxh32 (from $GOROOT)
        /***/gopath/src/github.com/pierrec/lz4/v2/internal/xxh32 (from $GOPATH)

[pierrec]

Modules are not supported by go versions < 1.10.
For go 1.9, you need to use this package version 2.0.4.

[laurikoobas]

Ok, that helped. Would be cool to have a mention of it somewhere :)

[slaterx]

@pierrec I understand your point, but I still would like to point out that this is a breaking change for anyone not running 1.10, or using modules, or doing plain go get instead of using dep, glide, etc.

Could you please point out what would be the directions for everyone not ready to use modules?

[deberth]

Actually I'm also getting the same error with go version go1.10 linux/amd64

[kjelle]

Building Shopify/sarama now fails because go get github.com/pierrec/lz4 fails.

I also run go1.10

[deberth]

Works with 1.11

[laurikoobas]

Yup, fails with 1.10, works with 1.11. The sad thing is that AWS CodePipeline doesn't have golang image for 1.11 yet, so I'm only left with 'dep' here. Which is not a bad thing.

[xxx7xxxx]

Mac pro with golang1.11 failed in glide install with https://github.com/Shopify/sarama .

[ERROR]	Error scanning github.com/pierrec/lz4/v2/internal/xxh32: cannot find package "." in:
	/Users/longyun/.glide/cache/src/https-jackfan.us.kg-pierrec-lz4/v2/internal/xxh32

[mundrapiyush]

Facing the same issue with Go 1.9 . How to solve ?

> ../../../github.com/pierrec/lz4/reader.go:9:2: cannot find package "github.com/pierrec/lz4/v2/internal/xxh32" in any of:
> 	/usr/local/go/src/github.com/pierrec/lz4/v2/internal/xxh32 (from $GOROOT)
> 	/home/dca-api/src/github.com/pierrec/lz4/v2/internal/xxh32 (from $GOPATH)

[pierrec]

Sorry about the inconvenience. Working on a fix ASAP.

[slaterx]

For everyone doing plain go get, this was the workaround I've done while a fix is being developed:

git clone -b 'v2.0.4' --single-branch --depth 1 https://github.com/pierrec/lz4.git $GOPATH/src/github.com/pierrec/lz4

[pierrec]

As per https://github.com/golang/go/wiki/Modules#semantic-import-versioning:
either we use a module compatible go version (1.9.7+, 1.10.4+ or 1.11+) or create a v2/ subdirectory.

Since option 1 is not practicable (older releases of go may still be in use), and I don't think option 2 is satisfying, I believe that the change needs to be reverted.
Thoughts?

[dayadev]

Option 2 is not bad.

openzipkin/zipkin-go-opentracing fails due to reason that it cannot find package "github.com/pierrec/lz4/v2/internal/xxh32"

[nvnobelen]

FYI: The change also breaks 1.10.1-r0 in alpine

[snowzach]

If you change the default branch to v2.0.4 I think go get will check out the default branch and it will work until everyone is on go modules.

[myusuf3]

this is breaking our build, what needs to happen here for golang1.9?

[pierrec]

@myusuf3 You need to upgrade 1.9 to 1.9.7. I have tested it successfully with this pkg at its current state.
@nvnobelen yes, anything 1.10 before 1.10.4 breaks because of having v2 in the import path.
@dayadev option2 would work but I dont think it is nice in the long run.

If no one objects to it, I will roll back the module support for now, until everyone is on a version of go that supports modules (that is 1.9.7+, 1.10.4+, 1.11 as we speak). Knowing when that happens may prove a challenge though...

[slaterx]

@pierrec is there a way you can apply the module update and not have the v2 in the import path? This way, both old and new go versions will be pleased.

[pierrec]

@slaterx this is what I have tried to figure out without luck. Changing the import path by suffixing it with the version (if that version is > 1) is the way it is implemented in go modules.
The only option that preserves both sides is copying everything over to a v2/ subdirectory. This means duplicating all the code and having a v3/ if one comes out, which I am reluctant to do.
Still thinking over it.

[snowzach]

I think the idea behind the major version number changes is that you increment from 1->2 when you have breaking changes in the library. This allows you to depend on versioned APIs github.com/blah/blah/v2 etc...

In the case of this library, I think you can remove the /v2 from the end of the module path in go.mod. Yes your release version says v2.0.0 but I think it will still carry on working.

If, down the road, you want to make breaking changes to the library, I would probably create a v3 branch and change the module to say /v3 at the end.. There would be no /v2 import path for this library in that case. The default import would be v2. All commits would go to the v3 branch and the release tag would point to that branch which is what go modules would use to find the right code.

I'm just guessing here, but I'm pretty sure that's what needs to be done to get us all working again.

[pierrec]

@snowzach I think you have found the right solution. Testing it locally works for old versions of go as well as new ones that do support modules.
Thanks!

[pierrec]

Closing.

[bcmills]

In the case of this library, I think you can remove the /v2 from the end of the module path in go.mod. Yes your release version says v2.0.0 but I think it will still carry on working.

I don't think that works. See https://golang.org/issue/25967#issuecomment-422828770 and golang/go#28336.