Vscodium: VSCodium checksums do not match

[Thilas]

Describe the bug
I am maintaining the Chocolatey package for VSCodium and latest release seems to be frequently updated with new installers (i.e. new checksums) since 1.3.5.0.

In the context of a Chocolatey package, this is an issue because the checksum is done once and is not expected to change overtime (see https://github.com/Thilas/chocolatey-packages/issues/15).

Please confirm that this problem is VSCodium-specific

• [x] This bug doesn't happen if I use Microsoft's Visual Studio Code. It only happens in VSCodium.

Please confirm that the issue/resolution isn't already documented

• [x] I checked the Docs page and my issue is not mentioned there.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://github.com/VSCodium/vscodium/releases
2. Checksums change frequently (everyday?)

Expected behavior
Is this possible not to overwrite GitHub latest release like it used to? Any thoughts about this?

Desktop

• OS: Windows
• Architecture: x64, ia32
• Version: 1.35.0

[CatKasha]

How about this?
Instead of overwrite the current release on GitHub, make the next release with additional version to the release (1.35.0.1, 1.35.0.2, 1.35.0.3, etc.) if something needs to be fix in the current release

[stripedpajamas]

I definitely try to avoid overwriting releases when possible for this very reason. When 1.35.0 built, we did see the version file fail to update, so 1.35.0 was built twice more (as a part of #185). Any build+release takes 20+ minutes and looking at the build logs the last "big" build was Monday 9.39pm (unsure of timezone), which is when I updated the Windows builds to make their version updating more resilient.

What is the timeline for the multiple checksum mismatches on the Chocolatey side @Thilas ?

[Thilas]

I am not sure to understand your question.

Regarding Chocolatey, here is how the auto update process works:

• an automated process checks 4 times a day for new releases
• if a new release is detected, then it downloads the installers (x86 and x64) in order to generate both checksums (it could use the published checksum files instead but it wouldn't change the issue)
• then a new version is published on Chocolatey including both checksums and installer uris (the ones released on GitHub)

Obviously, if the installers change on GitHub after this publication on Chocolatey, users will just get the checksum mismatch.

I perfectly understand the need to republish a given release as I have the same concern for Chocolatey packages.But IMO, it should be handled with dedicated build numbers as mentioned by @CatKasha.

[stripedpajamas]

Will take the build number suggestion, per @CatKasha. Thank you both 🙏

[Thilas]

Thanks @stripedpajamas!

[ghost]

maybe too late, but here's some suggestions-

I think this issue could be handled in another way.

(1.35.0.1, 1.35.0.2, 1.35.0.3, etc.).

The one-to-one correspondence between vscode and vscodium is great, for one; it makes sense to not bump version numbers for vscodium; as its not a fork.

---

(1.35.0.1, 1.35.0.2, 1.35.0.3, etc.).

can you discuss using another versioning scheme?
VS-Code-version-date-time. eg:- 1.35.0-date-time
VS-Code-version-rebuild1. eg:- 1.35.0-rebuild1

as long as its easy to find the corresponding vscode build-version.

---

side note on chocolatey process-

>downloads the installers ... in order to generate both checksums (it could use the published checksum files instead but it wouldn't change the issue) >**in order to generate both checksums** wastes compute & time, no benefits. why not use the published ones if they are provided?

[Thilas]

@snow8gaia, thanks for your remarks. Regarding chocolatey, the checksums are embedded within the published nupkg. So whatever the way checksums are gathered, it won't fix my original issue.

Besides, since I compute the checksums only once per GitHub release, the waste is not that huge... even if I agree with you that it would be better to use the provided checksums.