flame 0.7.0

flame 0.7.0 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.7.0/flame ccfb8c22261a694153b4ff0ba849bfdc0b718fcdaad919be36a8d69e53c225b6
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Pass the signing seed to the release workflow (#33)

Releases now receive the signing seed, so they can sign their executables.
The release job runs in the release environment, which holds UPGRADE_SIGNING_SEED, but it still saw the secret as empty and refused to release:

release: etc/keys/release.pub exists, but UPGRADE_SIGNING_SEED is not set; it is the secret of the `release` environment

A reusable workflow sees only the secrets its caller passes, even those of an environment its own job names. This passes them with secrets: inherit, as Pyrocosm's release workflow already does for PROPAGATE_TOKEN. The seed is still an environment secret, so only a version tag can reach it, and only after a reviewer approves the job.

actionlint is clean on the workflow. The next tagged release is the real test, and it stops before publishing anything if the seed is still missing.

Take the version from the release tag alone (#32)

A release's version is now declared once, by its tag. There is no flameVersion to bump before tagging, so a tag can no longer disagree with build.mill and fail the release.

• settings.version gives FLAME_RELEASE_VERSION when a release or snapshot sets it. Otherwise it gives the patch after the latest release tag reachable from HEAD: 0.7.1 after 0.7.0, which sorts after that release and before whichever follows. Where no release tag is reachable, as in CI's shallow checkout, it gives 0.0.1.
• publishVersion is that version, and buildVersion is that version plus the tree hash outside a release.
• The launcher resolves flame-client at client.publishVersion(). In a release that is the tag's version, which is the coordinate Burdock must externalize against.
• make snapshot takes its base from ./mill show flame.client.publishVersion, so a snapshot after 0.7.0 is 0.7.1-<hex>.
• The release instructions in the Makefile and docs no longer ask for a bump. release.sh already skips its pin check when build.mill declares no version.

A development build's publishLocal also no longer installs jars under a released version, where they could shadow the real release in ~/.ivy2/local.

Verified locally:

• ./mill show flame.client.publishVersion gave the patch after the latest local tag.
• With FLAME_RELEASE_VERSION=9.8.7, publishVersion and the launcher's mvnDeps both gave 9.8.7.
• buildVersion gave the next version with the tree hash.

Recovery and release keys (#31)

Package with xek 1.3.0, and release in the release environment (#30)

Packages flame with xek 1.3.0, and prepares its releases for signed executables that can upgrade themselves.

• etc/xek.tsv pins xek 1.3.0. Its digest matches xek's published 1.3.0.SHA256SUMS.
• make flame runs dist/xek build, since every xek command line from 1.1.0 begins with a subcommand.
• etc/github-ref moves to the shared scripts with propensive/.github#34 and #35. Those scripts build with the build subcommand, and sign the executables once etc/keys is committed. They also attach upgrade.tsv to every release and write install.ps1 with xek installer. etc/shared takes the canonical copy, which differs only in a comment.
• release.yml runs the release in the release environment, which holds the signing seed.

propensive/.github#34 and #35 are merged, and etc/github-ref pins their merge commit. Create the release environment with bin/settings apply flame before the next tag; otherwise GitHub creates it on the first release with no protection.

With this alone, the next release is built and published unkeyed, with a note saying so. It becomes the first signed release once etc/keys/release.pub and recovery.pub are committed.

Also:

• make flame builds with --java-min 25 --java 25, as released executables now do: an installed Java older than 25 is passed over, and Java 25 downloaded.

Run fume 0.7.0, flair 0.6.0, flame 0.6.0 (#29)

Moves etc/tools to the latest releases of the tools this repository runs: fume 0.7.0, flair 0.6.0, flame 0.6.0.
fume 0.7.0, flame 0.6.0 and flair 0.6.0 are built against Soundness 0.71.0 and Pyrocosm 0.6.0. Nothing else changes.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.7.0.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.7.0

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and flame-windows-x64.exe); flame, the polyglot
bootstrap — a small any-shell script, to be renamed flame.bat or flame.ps1 on Windows, which
downloads the right executable, verifies its checksum, replaces itself and re-invokes; and
install.sh and install.ps1, which https://propensive.dev/flame serves. Each executable
externalizes the libraries above, resolving further dependencies from the Soundness and proscala
releases and from Maven Central on first run.