Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reverts #562 where we added support for vgo. I'd tested vgo's behavior on a simple synthetic versioned repository before merging #562, but apparently it wasn't enough because I'm unable to correctly add stripe-go with vgo even with the addition of a `go.mod` and corresponding tag. Here's the resolution error when trying to build a test project: ``` $ vgo build vgo: resolving import "github.com/stripe/stripe-go/v30" vgo: finding github.com/stripe/stripe-go/v30 (latest) vgo: adding github.com/stripe/stripe-go/v30 v30.8.1 vgo: finding github.com/stripe/stripe-go/v30 v30.8.1 vgo: downloading github.com/stripe/stripe-go/v30 v30.8.1 vgo: resolving import "github.com/stripe/stripe-go/form" vgo: finding github.com/stripe/stripe-go (latest) vgo: adding github.com/stripe/stripe-go v1.0.3 vgo: import "github.com/brandur/stripe-go-vgo" -> import "github.com/stripe/stripe-go/v30": found in both github.com/stripe/stripe-go v1.0.3 and github.com/stripe/stripe-go/v30 v30.8.1 ``` I think what's happening is that it correctly sees the `v30.*` tag and resolves that, but then it starts to descend into subpackages, and eventually finds one that references the top-level package (almost all of them do, but take `account/` as an example). The import doesn't use the `stripe/stripe-go/v30` suffix, and therefore vgo tries to resolve a difference package version (once again falling back to `v1.0.3`), and produces a conflict. I think the fix is to make sure all imports end in `/v30`, but this is very problematic from two angles: 1. It breaks out compatibility with non-vgo installations. 2. It forces us to update the import path on dozens of subpackages every time we do a new major release, which is very bad. For now, I'm going to revert this. Hopefully some progress on vgo in the future makes this a little easier.
- Loading branch information