Re: Bug#1059083: golang-github-azure-azure-sdk-for-go: package outdated, upstream now versions components independently
Hi Daniel,
On 29/02/2024 8:43 pm, Daniel Swarbrick wrote:
Hi Maytham,
On 29.02.24 12:16, Maytham Alsudany wrote:
Could we avoid bumping the epoch by suffixing the version with the
git commit? e.g. for the case of azure-sdk-for-go, the next version
would be 68.0.0+git20240229.d33ad0-1s
I did this kind of thing previously for
golang-github-azure-go-autorest (14.2.0+git20220726.711dde1-1) since
it was in the same situation. However, it has a bad smell IMHO, as
there is little useful difference between 68.0.0+git20240229.d33ad0-1
and 0.0~git20240229.d33ad0-1. It completely throws semantic versioning
out the window.
Since the azure-go-autorest upstream seems to have more or less
resumed vX.Y.Z tagging (albeit lower version numbers than before -
most recent tag is "autorest/v0.11.29"), I would be more inclined to
bump the epoch and make the Debian version number e.g. 1:0.11.29-1
They're trying to version the tracing, logging, and autorest components
independently, but with the main functionality is the autorest
submodule, so it makes sense to version using that tag.
All that remains is to determine which series of tags in
azure-sdk-for-go is the "main" version number - and my gut feeling is
that it's the "sdk/azcore/vX.Y.Z" series.
Probably azcore, since all the other modules depend on it AFAICS.
I still think it's better to use commits for versioning, since the
modules are versioned independently and versions of submodules are
released after azcore, meaning package maintainers need to either wait
for the next azcore version, or prepare a orig tarball and add a +1 to
the version.
Putting another idea out there: why don't we do what the JS team does
(when vendoring packages), and just add all the submodule version
numbers together?
Have you checked what other distros are doing, assuming that they
package that project?
Other distros either don't package the project, or have v68.0.0.
https://repology.org/project/go:github-azure-azure-sdk-for-go/packages
Kind regards,
Maytham
Reply to: