Why does the release shasum keep changing?

[natevw]

This is depended on by https://github.com/DesktopECHO/android-studio-aarch64-install which checks the sha256sum of your release. In the last few weeks the checksum for the android-sdk-aarch64-linux-musl.tar.xz download of the "same" 37.0.0 release has changed from:

• b8424efb05ed7a25eb0ded8cea7f630ce59c9edab7ea06223aba9aa16bf40175

to:

• b904edf8cf20c233de9d884a2da4a8e7eadea4d23aa10859abb9466660f3e803

and now to:

• 1d9c475b70f66ec21dc225b25388214aaa41521000ee35a3fe89d8bb7ed467a6

What is going on here? I'm trying to understand why the "June 25" release keeps getting updated without changing versions.

[HomuHomu833]

basically 1d9c475b70f66ec21dc225b25388214aaa41521000ee35a3fe89d8bb7ed467a6 is due to #18 and toolchain version updates and for b904edf8cf20c233de9d884a2da4a8e7eadea4d23aa10859abb9466660f3e803 is probably toolchain version update or bugfixes, it's pretty much expected

[HomuHomu833]

llvm-custom, cmake-custom and android-ndk-custom sha's will also get changed as new target triples and older NDK versions will arrive soon

[natevw]

Thanks for background here! IIUC, the SDK itself remains as version 37.0.0 of that but the custom build is getting tweaks and changes in the meantime?

I can't speak for @DesktopECHO or others downstream, but I wonder if publishing with an additional patch version like 37.0.0.1 / 37.0.0.2 / 37.0.0.3 or a new release each time with some suffix like 37.0.0-build42 would help show when the build has changed even when it's the same SDK version?

[HomuHomu833]

Thanks for background here! IIUC, the SDK itself remains as version 37.0.0 of that but the custom build is getting tweaks and changes in the meantime?

Yes, that's right. There was a Zig update in July and yet another Zig update on Sep 18. Also, correcting myself from earlier: #18 only changed the bionic build.

I can't speak for @DesktopECHO or others downstream, but I wonder if publishing with an additional patch version like 37.0.0.1 / 37.0.0.2 / 37.0.0.3 or a new release each time with some suffix like 37.0.0-build42 would help show when the build has changed even when it's the same SDK version?

I'd rather not. The version follows Google's, so 37.0.0 is their number, not mine. I can't invent 37.0.0.1 or a build suffix without it no longer matching what Google actually ships.

[joebowbeer]

I think it would be a good idea to make the releases immutable: for better security, reproducible builds, and compatibility with tools such as renovate and dependabot.

I think this can be achieved by adding a prerelease suffix to the release tag.

In this case, the prerelease suffix could be as simple as a dash (-) followed by an update number (3)

37.0.0-0
37.0.0-1
37.0.0-2
37.0.0-3

https://semver.org/

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--.

Note that I'm not recommending the +build suffix because it doesn't sort.

[DesktopECHO]

All good, I will mirror SDK/NDK snapshots on my repo and update the mirror as needed.