Hi Simon, On Wed, 2026-03-18 at 11:46 +0100, Simon Josefsson wrote: > Yes, although I'm slowly ariving at a position that this is all just > arbitrary and subjective, and we already have several different styles > in the archive, so nothing we will document will move the needle > substantially. So when reviewing doc changes, we have to decide if our > NEW documentation on this should introduce a conflict against what's in > the archive, or chose some other stragegy, including: > > 1) Weasle word things a'la "The following single approach is what we > recommend, but other strategies exists". > > 2) Describe several different methods, with details, possibly including > a team-wide preference (if there is one).
Either way would work, but both mean that we need to decide which approach makes the most sense to recommend be used in most situations. I'm encountering this problem regularly[1] and would benefit from having this discussion to make it clear which method is considered "best practise". Renaming only the binary package (adding or incrementing the prefix from -v5 to -v6) makes the most sense as it matches roughly what happens with C library transitions, where a SONAME bump will trigger a binary package rename while the source package name remains the same (binNEW). From my understanding of how the archive works, this might be problematic since the archive will only retain the previous -v5 binary package of other **binary** packages still **Depends** on, and will ignore Build-Depends (and therefore cause FTBFS in Golang end-user programs which do not Depends on library packages like -dev packages do). Please correct me if I'm wrong. The other approach, which I am leaning to and have already used in the past, is renaming the source package as well. This is a guaranteed way to avoid rdeps breaking due to a package update, since packages can still reliably Build-Depends and Depends on the -v5 package. It also means that -v5 can still be updated for any reason (e.g. security update, patch). Thanks for bringing this up, Maytham [1] Recently I uploaded golang-github-urfave-cli-v3, now I'm trying to figure out how to deal with the charmbracelet packages all releasing new major versions with breaking changes (including a change in their import paths from github.com/charmbracelet to charm.land). Another one is github.com/dnaeon/go-vcr (v1) => gopkg.in/dnaeon/go-vcr.v4.
signature.asc
Description: This is a digitally signed message part
