Skip to content

Release tag/name version and released file versions differ by a .0 #360

Description

@brettcannon

The released files for the WASI SDK all have a .0 at the end of their version, while the release names/tags don't. For example, https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-20 has https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-20/wasi-sdk-20.0-linux.tar.gz ; notice the 20 in the tag name but 20.0 in the file name.

This makes it a little tricky to download files as both names are used in the URL. For example, in a Docker file I have (notice the hard-coded .0 in that URL):

ENV WASI_SDK_VERSION=20
curl --location https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-${WASI_SDK_VERSION}/wasi-sdk-${WASI_SDK_VERSION}.0-linux.tar.gz

Making sure to not leave off that .0 is easy to forget. Same goes for where the tarball expands to (luckily in this case I can use tar --strip-components 1 --directory ${WASI_SDK_PATH} to avoid this, but on my development machine I can't).

Any chance future git tags/GitHub releases can include the full version?

Activity

  1. abrown commented on Dec 18, 2023

    @abrown
    Collaborator

    For wasi-sdk-21, I thought about this a bit: on the one hand, whatever scripts are out there have probably adapted to this inconsistency so "fixing" it might actually break other people's workflows. Also, having the minor version present is probably useful in case someone needs to patch a release. On the other hand, perhaps we could tag releases twice: wasi-sdk-N and wasi-sdk-N.M. Then users of wasi-sdk could choose whichever tag best suits their workflow. That could get confusing, though, so ideally we could improve the release workflow in CI to just "do the right thing" automatically.

  2. brettcannon commented on Dec 19, 2023

    @brettcannon
    ContributorAuthor

    whatever scripts are out there have probably adapted to this inconsistency so "fixing" it might actually break other people's workflows.

    True (me included).

    Also, having the minor version present is probably useful in case someone needs to patch a release.

    But if that was ever not .0 then that would also break people.

    No good options, unfortunately, short of getting into package managers so it's their problem. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions