.. > >> Since golang-github-cenkalti-backoff is already at v5 in > >> experimental, I suggest we package v4 as > >> src:golang-github-cenkalti-backoff-v4 which produces > >> golang-github-cenkalti-backoff-v4-dev. > >> > >> This -v4 package would then live in unstable side-by-side with the > >> v5 code in the existing binary packages. This will break existing > >> packages, which will need to be fixed by either porting them to v5, > >> or updating debian/control to build against > >> golang-github-cenkalti-backoff-v4-dev. > > > > Even though this is a bit painful, I still think it is the best thing > > to do. The package name that is "versionless" should be reserved for > > the latest version, and if older versions are needed to be kept > > around, they should have the version suffix. > > Great, we have some agreement on this then.
One more option came to my mind here: vendoring. You could put the v4 into debian/vendor/github.com/.../v4 In particular if: - the dependency is not properly defined, a local debian/vendor/* thing is easier to inject into the build - the dependency is very specific, e.g. v4.x.y - you don't want to go via NEW queue to introduce a -v4 package - only one or _very few_ packages depend on it and no new packages will ever depend on it
