Bug#1059083: ITP: golang-github-azure-azure-sdk-for-go-sdk -- Microsoft Azure SDK for Go (track2)
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)
Reply to: