Maytham Alsudany <[email protected]> writes: > 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).
I prefer that approach, mostly because it lets me introduce a new upstream version orthogonally to all existing packages in the archive. I've done coordinated migrations to a newly introduced golang-*-vOLD-dev package, and I found it really painful and boring. IMHO it is a better workflow to introduce a new golang-vNEW package, incrementally transition consumers of it, and then eventually remove the old package. Then maintainance work doesn't get entangled with new work. I've also used other approaches. So I don't care strongly. Some I would not use again, unless really needed, like producing combined vX+Y packages. For some migrations, I setup a separate Salsa project for different versions of the same upstream. I realize there is no need to do that: you can keep one Salsa repo per upstream package, and support multiple golang-vX Debian source packages in separate branches. This is somewhat heavy to work with, though. I'm still not certain what I prefer there. /Simon
signature.asc
Description: PGP signature
