Sorry, Francesc, my bad. I think I assumed that since you overwrote the old v1 API in place, you were for some reason not worried about breaking existing code. Because that’s what it does, modules or not. That is, changing github.com/dgraph-io/badger from the v1 API to the v2 API breaks all users who do a fresh go get of anything that imports github.com/dgraph-io/badger expecting the v1 API. As it has said in the Go FAQ for a long time (my emphasis):
Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don’t remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path.
If you don’t want to break any existing users, you should follow adg’s advice above, which is:
- roll the repo back to the latest v1 API
- create a v2 subdirectory containing the v2 API
For Go modules users you should also create a v2/go.mod that says module github.com/dgraph-io/badger/v2 before you tag it v2.0.1 (or whatever your next unused version number is).
At this point every tool, including dep, govendor, and go get all the way back to Go 1, will understand the difference between github.com/dgraph-io/badger and github.com/dgraph-io/badger/v2 and know where to find each.
Yes, you will still have the v1 API in the repo alongside the v2 API, but that’s the cost of not breaking your users. And if you need to update a security or other fix for v1, it’s easy to do and will work just fine when go get, govendor, or any other tool fetches the update.