Check out our GitHub!

cargo-dist

Version 0.13.0 (2024-04-09)

v0.13.0 Apr 9 2024 at 13:11 UTC

This releases introduces a 'selfupdate' command, using cargo-dist's new updater support.

It also includes several bugfixes and a technically-breaking-change to the dist-manifest feature.

Features

A new cargo dist selfupdate command has been added which updates cargo dist to the latest version and runs cargo dist init using that new version. As a result, this should in be a go-to replacement for most uses of cargo dist init.

This is based on the new experimental axoupdater library. Essentially it just checks GitHub Releases or axo Releases for anything newer, and fetches and runs the appropriate shell/powershell installer.

This library is the same one used for the updater feature of cargo-dist, which has cargo-dist provide a standalone separate updater binary. The benefit of us using the library directly is that we get a more unified design at the cost of needing to actually change the interface of our application -- something the separate binary avoids.

Breaking Change

This release makes a several changes to the dist-manifest format which ideally shouldn't be breaking in the strictest sense of the word, but are breaking in spirit. No one is expected to be effected, as the metadata in question is so niche that not even axo's own tooling was making a use of it.

The upshot of this breakage is that we now properly collect and merge unambiguous per-platform and per-binary metadata from build machines, which is groundwork for significantly improved installers and tooling.

Changes include:

  • there is now a top-level systems map in the manifest
    • contains gathered information about each system cargo-dist ran on to build your release
    • this effectively deprecates the system_info value, which was already optional and not terribly useful
  • there is now a top-level assets map in the manifest
    • contains gathered information about each binary cargo-dist built
    • refers to the systems{} that the binary was built on
    • contains linkage info
  • the top-level linkage array has been deprecated in favour of the same entries being nested in assets, and is now always empty
    • in future versions it may be removed, but the schema didn't mark this field as optional so it can't yet be removed
  • artifacts{}.assets[].id now can optionally refer to an entry in assets
    • this allows you to precisely get the dependencies (linkage) for each binary in an archive, or for the whole archive (by merging them)
    • in the future it will also be used to get things like libc version requirements
  • artifacts{}.checksums{} has been added
    • contains the actual checksum value(s)
    • the existing artifacts{}.checksum only refers to a checksum file, as previously the manifest could not be updated with "computed" info
    • this being a map allows artifacts to have multiple checksums, which is useful since lots of things hard require sha256

Fixes