[ I'm dropping the ITP bug from CC ]

Am 14.02.26 um 21:28 schrieb Simon Josefsson:
> The motivation is that whenever v6 comes around, what would you do?
> Upgrade golang-github-jackc-pgx-v5 to hold v6?  That would be really
> confusing.

Sure, that would be confusing and wouldn't make sense. I wouldn't do that.

My understanding is that golang-github-jackc-pgx-v5 will stay at v5 of
that package forever.

If upstream releases v6 of their package, we would introduce a new
package, called golang-github-jackc-pgx-v6.

> Thus it seems better for golang-github-jackc-pgx to track latest
> upstream version, and if there are packages in Debian that cannot be
> upgraded, then package golang-github-jackc-pgx-vX for the earlier
> version, and migrate the broken packages to it.  We went through this
> recently.

Well, that's also possible. However, I think the approach with using an
explicit "-vX" suffix on the source package name is better, because it
stays in sync with the name of the binary package.

Also, if I understand it correctly, it's more or less the same amount of
work -- just the other way round, right? Either we create a new package
with -v5, or we update the existing (versionless
golang-github-jackc-pgx) package to v5 and introduce a -v4 package for
the remaining reverse dependencies which cannot be upgraded yet.

> For cases where there is only one or very few packages that is stuck on
> an old version, I think it is reasonable to consider somehow vendoring
> files and/or shipping both version somehow.  It is ugly though.

Yes, that's not ideal, I agree. That can be avoided by using -v4 and -v5
packages, respectively. The packages which are stuck on the previous
version of a golang library can just Build-Depend on the -v4 package.

> Is it possible to establish any concensus on this?
> 
> Alas it seems the consensus process for the Go team to make updates to
> the Go Team Policy is dysfunctional.

Hm, I think we're getting started having a discussion on this list and
share ideas. Maybe we get a consensus. :-)

Regards,
Tobias

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to