Package: wnpp Followup-For: Bug #1059083 I got wind of this azure-sdk-go issue from monitoring the rclone status (I'm ready to update other rclone components like anacrolix-dms when the new rclone is ready to proceed).
Has the version numbering question been settled? Looks like upstream has made a mess of it. Each subcomponent gets its own version, fine, but then each tarball for that version contains the contents of all the other subcomponents at their git half-state. It's chaos. Using 68.0.0+git* is a reasonable workaround for the upstream versioning challenge. My only request is that (in general at least) the tarball be taken from an official release tarball (https://github.com/Azure/azure-sdk-for-go/tags) not git HEAD. I don't think that could be done automatically with debian/watch, so updating would have to be done manually e.g. gbp import-orig --pristine-tar https://github.com/Azure/azure-sdk-for-go/archive/refs/tags/sdk/messaging/azservicebus/v1.10.0.tar.gz for their latest non-beta release, which was azservicebus/v1.10.0 (so 68.0.0+git20250806.2cd8651). I agree with Daniel Swarbrick that the +git numbering doesn't look great when there are actual release versions, though Microsoft hasn't made it simple with Daniel Swarbrick. One suggestion then is to update the number according to the official release version, rolling with the subcomponent. A prefix to the suffix could be used to give ordinal order when necessary. Needs manual control but that's the case now anyway with this package, unless you plan to only track git HEAD and not official releases. e.g. looking back at the last most recent official releases sdk/internal/v1.11.2 → 68.0.0+1+internal.1.11.2 or 68.0.0+git20250729.066f6f9+internal.1.11.2 sdk/resourcemanager/avs/armavs/v2.1.0 → 68.0.0+2+armavs.2.1.0 or 68.0.0+git20250729.76d9191+armavs.2.1.0 (git tag is dangerous here: armavs/v2.1.0 was released the same day as internal/v1.11.2 but the git hash decreased ordinally. In practice can hopefully avoid this kind of clash). sdk/azcore/v1.18.2 → 68.0.0+2+azcore.1.18.2 or 68.0.0+git20250731.362bc89+azcore.1.18.2 sdk/azidentity/v1.11.0 → 68.0.0+2+azidentity.1.11.0 or 68.0.0+git20250804.8142fe3+azidentity.1.11.0 sdk/messaging/azservicebus/v1.10.0 → 68.0.0+2+azservicebus.1.10.0 or 68.0.0+git20250806.2cd8651+azservicebus.1.10.0 (I would not package beta releases if they are not needed, so I'm ignoring sdk/resourcemanager/mongocluster/armmongocluster/v1.1.0-beta.1) I guess the git suffix gives cleaner ordering, but adding the official release tag as a suffix can clarify which release version it means exactly (and that it's not simply taking git HEAD)
