Release v1.5.2 requested #589
Description
I have been testing recent changes extensively, and after #586, #587, #588 land I believe LCM will be in great shape for my ecosystem of users. I would like to publish to https://registry.bazel.build/, and that would be easier if there was an official v1.5.2 release tagged from the latest master after those merge. Would you consider tagging a new release after those PRs?
Second request -- after the next release, it would help if you could download the Source code (tar.gz) link from the release and then re-upload it as a release attachment. The auto-generated Source code (tar.gz) used by downstream package managers is actually not checksum-stable per GitHub. When unpacked it will be invariant, but the tar and gz process can change how they encode and compress the data. For packaging ecosystems that verify checksums, this can lead to failures down the road. Packagers always need a separate attachment of sources; the auto-generated ones are (unfortunately) unsuitable.
See https://github.com/orgs/community/discussions/46034 for details. Here's google's AI Overview FWIW:
GitHub's approach to release checksum stability distinguishes between two types of archives:
Uploaded Release Assets:
These are files (e.g., binaries, archives) that a repository maintainer explicitly uploads to a GitHub Release. GitHub guarantees the stability of these assets and their corresponding checksums. As of June 2025, GitHub automatically computes and displays SHA256 checksums for all uploaded release assets, making verification straightforward via the UI, API, or gh CLI.
Dynamically Generated Source Code Archives:
These are the "Source code (zip)" and "Source code (tar.gz)" files automatically generated by GitHub for each tag or release. The checksums of these archives are not guaranteed to be stable. They are generated on-demand using git archive and are sensitive to changes in Git's internal mechanisms (e.g., compression algorithms, versions of underlying tools like tar or gzip). A notable incident in early 2023 demonstrated this when a change in Git's default compression caused checksums of these archives to change, even though the content remained the same, impacting systems relying on their stability.
In summary:
For stable and reliable checksums, always use explicitly uploaded release assets. These are guaranteed to remain unchanged once published.
Checksums of dynamically generated source code archives are subject to change: and should not be relied upon for integrity verification if long-term stability is required. If using these, be prepared to update checksums if they change due to GitHub's internal updates.