The latest commit (move stuff to v2) breaks package with go 1.10 and earlier about lz4 HOT 23 CLOSED

Sorry about the inconvenience. Working on a fix ASAP.

from lz4.

@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?

from lz4.

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

from lz4.

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

from lz4.

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

from lz4.

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

I also run go1.10

from lz4.

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

from lz4.

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

from lz4.

Works with 1.11

from lz4.

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.

from lz4.

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-github.com-pierrec-lz4/v2/internal/xxh32

from lz4.

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)

from lz4.

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?

from lz4.

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"

from lz4.

FYI: The change also breaks 1.10.1-r0 in alpine

from lz4.

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.

from lz4.

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

from lz4.

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

from lz4.

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

from lz4.

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.

from lz4.

@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!

from lz4.

Closing.

from lz4.

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.

from lz4.