Can't upgrade to version 2.0.5

[kolaente]

I can't upgrade to version 2.0.5 on go 1.14:

$ go get -u github.com/mattn/go-sqlite3@v2.0.5
go: finding github.com/mattn/go-sqlite3 v2.0.5
go get github.com/mattn/go-sqlite3@v2.0.5: github.com/mattn/go-sqlite3@v2.0.5: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I suspect this is because go-sqlite3 does not respect the go module semantic versioning path.
I'll try to send a fix.

Related: golang/go#35732

[mattn]

@bcmills Any way to fix this issue without make v2 ?

[vtolstov]

remove go.mod and go.sum files. so go get don't think that this go modules enabled repo and follow tags as usual

[kolaente]

IMHO you should change the import path because that is the intended way of using go modules. Removing all traces of go mod often causes problems when used in go mod packages.

More info: https://blog.golang.org/v2-go-modules

[bcmills]

@mattn, you could resume v1.14.0 as the “latest” release (per https://golang.org/doc/go1.14#incompatible-versions), or change the import path to …/v2 or …/v3.

(Semantic import paths are, by design, not optional.)

[mattn]

@bcmills However, I have already released v2.0.0 or a newer version in a manner that is consistent with the semantic version. Can users of my module easily upgrade to v1.14.0?

[bcmills]

Yes. (See the release note linked above for details.)

[mattn]

Thank you.

[mattn]

@bcmills

Hmm, I still not really understand. My opinions are:

• I don't want to create v2 directory
• I don't want to modify module in go.mod
• I don't want to create v3 tag
• I want to provide an easy way for all users to upgrade go-sqlite3
• I want to keep using go.mod since this is useful to resolve dependencies.

Users who already upgraded to v2.X.X can get back to v1.14.X ?

BTW, If I move this repository into another places, Am I possible to restart to make version v0.0.1 ?

[kolaente]

You don't need to create a v2 folder, only a git tag with the version (which you already have) and then modify the module line in your go.mod file to something like module github.com/mattn/go-sqlite3/v2. That's how modules work.

Why don't you want to modify module?

Upgrading is still easy, users will need to modify their usages in import paths, yes, but that's by design. Usually major version changes mean breaking changes which force users to do changes in their code. Therefore, if users need to change the import path everywhere they will see and modify the usages of the package.

[aofei]

BTW, If I move this repository into another places, Am I possible to restart to make version v0.0.1 ?

If you're willing to use a brand new module path, then it's possible.

GORM v2 just did it. Its author transferred the project from his personal account to the go-gorm/gorm, and maintained the original project jinzhu/gorm as a fork. By doing so, he can keep existing users from being broken. And, most importantly, he can safely clear all tags and start over with a brand new module path gorm.io/gorm that is different from the old github.com/jinzhu/gorm.

BTW, I just saved you the GitHub username go-sqlite3, I can transfer it to you if you want. :-)

[mattn]

@kolaente

Why don't you want to modify module?

Upgrading is still easy, users will need to modify their usages in import paths, yes, but that's by design. Usually major version changes mean breaking changes which force users to do changes in their code. Therefore, if users need to change the import path everywhere they will see and modify the usages of the package.

Because the users that uses go-sqlite3 won't notice new v2 or v3. When did use v1.X.X, I could provide way to upgrade easily.

[kolaente]

But if you're releasing v2 that means breaking changes. Therefore your users will need to touch their application if they want upgrades. That's the whole point of semantic versioning. If you release a v2 without breaking changes, it's not a v2 and should not be released as one.
As @bcmills already said "Semantic import paths are, by design, not optional.".

How hard or easy you make it for users to adopt the new version depends on you. Right now, it is hard because the module does not play with the go mod ecosystem which makes it impossible to use the new version in any go mod project.

[bcmills]

@mattn, you can satisfy most of your requirements by tagging the next release as v1.14.0 and including a go.mod file in it.

However, in order for users who already depend on v2.0.0 through v2.0.3 to upgrade to that version, they will have to prune out any existing dependencies on those versions, then run go get github.com/mattn/go-sqlite3@v1.14. (After that point, go get -u should keep them on the v1 line.)