All, I realized there is another approach to golang-* version transitions, keeping the source package name stable (corresponding to upstream unversioned name) but modifying the binary package names. 1) Use source package name after upstream namespace, e.g., golang-github-foo-bar. Let's say the current version is v5 and we want to transition to v6. 2) Upload to experimental dropping the old golang-*-dev binary package for v5 (typically it would be named golang-github-foo-bar-dev or golang-github-foo-bar-v5-dev) and add a new binary package called golang-github-foo-bar-v6-dev. This has to pass NEW for a new binary package, but NEW processing is fast now. 3) Upload all reverse dependencies to experiemntal building against the new golang-github-foo-bar-v6-dev. 4) If some reverse dependency REALLY REALLY cannot move to v6, we need to add a new source package golang-github-foo-bar-v5 to the archive, to build the old binary package, typically golang-github-foo-bar-dev or golang-github-foo-bar-v5-dev. This can go directly to unstable, and the reverse dependency that is stuck can be updated to use that new package. 5) Once all packages build against either golang-github-foo-bar-v6-dev, or the newly introduced backwards-compatibility golang-github-foo-bar-v5-dev package, upload everything to unstable. Thoughts? I really don't care, but I think we should have the strategies well documented, because this is tricky for us all. Maybe we can give up on recommending any particular strategy and just document all three distinct approaches that I'm aware of. I have to admit that I somewhat prefer the model to just introduce new source packages for new API versions, and make the packages that need the new version directly use them. This avoids having to touch or modify any old packages. Over time this will be a mess, but it may be less costly to solve than incremental transitions. /Simon
Attachment:
signature.asc
Description: PGP signature