Update import paths, examples and docs with new module name

[webstradev]

Closes #92

[penberg]

Thanks @webstradev!

[haaawk]

Isn't this breaking existing users?

[webstradev]

Isn't this breaking existing users?

If the previous module is still at the same address it won't break for them, it just means they won't be able to get newer versions from that address. But it might also be that go get handles the redirect in the same way github does.

[penberg]

Yes, but that's the price we pay for moving the repository to a different organization.

The error message is pretty helpful, though:

penberg@vonneumann xxx % go run main.go
main.go:4:2: github.com/libsql/libsql-client-go@v0.0.0-20231216074759-c5236f967155: parsing go.mod:
    module declares its path as: github.com/tursodatabase/libsql-client-go
            but was required as: github.com/libsql/libsql-client-go

@haaawk or are you thinking of some other solution to this?

[webstradev]

You could fork the commit before this was merged in and leave it at the old address as well i f that org is still in your control

[haaawk]

Yes, but that's the price we pay for moving the repository to a different organization.

The error message is pretty helpful, though:

penberg@vonneumann xxx % go run main.go
main.go:4:2: github.com/libsql/libsql-client-go@v0.0.0-20231216074759-c5236f967155: parsing go.mod:
  module declares its path as: github.com/tursodatabase/libsql-client-go
          but was required as: github.com/libsql/libsql-client-go

@haaawk or are you thinking of some other solution to this? We could leave the package name unchanged for some time maybe.

[webstradev]

Would it not be better to keep the older version on the old URL and than add a message that this repository is continued at the new url. That way you have backwards compatibility. If we leave the package name unchanged for some time we just move the problem to later down the line right

[penberg]

@webstradev We of course have control over the original organization, but I am hesitant to make fork there because we may end up driving people to use the old version for new applications.

@haaawk I am not sure what leaving the old package name buys us because at some point in the future, we do want to move away from the libsql organization, then breaking apps just like we do now.

[webstradev]

Can we tag an older commit (pre this mr) with a version that people could then use. I think github will handle the redirect from old to new and then the go module would match the import path as well. Might be worth a try.

Not sure if it will actually fix the breaking issue because new users would probably still need to pin the use of thatt specific version but just an idea.

[haaawk]

@penberg I don't have the answer really. I guess we will see soon how many people are affected.

[webstradev]

@penberg @haaawk Might I suggest we tag this on main, so that we can easily instruct users to update to a minimum of version X.

I'm happy to do some quick digging (with the dependency graph) to see who is using this and open PR's on the respective repositories.