Deploy the website from its own release line

.github/workflows/release-website.yml

@@ -0,0 +1,78 @@
+name: Release website
+
+# The website's own release line, independent of the binary's (see
+# release.yml). A `website-v*` tag deploys the landing page — copy, layout, a
+# newly advertised release — without publishing a vump version or implying one
+# to anybody pinning it. The two tag shapes never collide: this one does not
+# start with `v`.
+on:
+  push:
+    tags:
+      - 'website-v[0-9]*'
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: pages
+  # A deploy in flight is left to finish. Cancelling one does not undo it; it
+  # just leaves Pages serving a half-known state.
+  cancel-in-progress: false
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - uses: actions/checkout@v7
+
+      # Unlike release.yml, this uses the composite action rather than the
+      # build in this checkout. What is being verified here is the website's
+      # own version against the pushed tag, not the binary being released, so
+      # there is no regression a freshly built vump would catch that a
+      # published one would not — and a Rust toolchain and a two-minute build
+      # would otherwise be dragged into a job that deploys static files.
+      - name: Check tag matches the website version
+        uses: okcodes/vump/.github/actions/check@main
+        with:
+          version: ${{ github.ref_name }}
+
+      - uses: pnpm/setup@v2
+        with:
+          # The version comes from website/package.json's packageManager field,
+          # so local development and this job cannot drift apart. There is no
+          # package.json at the repository root to fall back on — this is a Rust
+          # project with a site in a subdirectory.
+          package-json-file: website/package.json
+          install: false
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '26'
+
+      # The committed lockfile is the deploy's declared input. Nothing is
+      # resolved, pinned or discovered at deploy time — a build of this commit
+      # produces the same bytes today and next month.
+      - name: Install
+        working-directory: website
+        run: pnpm install --frozen-lockfile
+
+      - name: Build
+        working-directory: website
+        run: pnpm run build
+        env:
+          VITE_WEBSITE_BUILD_SHA: ${{ github.sha }}
+
+      - uses: actions/configure-pages@v6
+
+      - uses: actions/upload-pages-artifact@v5
+        with:
+          path: website/dist
+
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v5

.github/workflows/release.yml

@@ -3,7 +3,10 @@ name: Release
 on:
   push:
     tags:
-      - 'v*'
+      # Digit-anchored so a tag that merely starts with v — `voldemort`, a
+      # branch-shaped name — cannot start a release. `website-v*` does not
+      # match either, which is what keeps the two release lines apart.
+      - 'v[0-9]*'
 
 permissions:
   contents: write  # needed to create GitHub releases and upload assets
@@ -16,7 +19,7 @@ jobs:
     name: Verify tag and test
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v7
 
       - uses: dtolnay/rust-toolchain@stable
         with:
@@ -81,7 +84,7 @@ jobs:
             asset: vump-windows-arm64.exe
 
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v7
 
       - uses: dtolnay/rust-toolchain@stable
         with:
@@ -124,7 +127,7 @@ jobs:
       KEYCHAIN_NAME: ci-signing-${{ github.run_id }}.keychain
 
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v7
 
       - name: Download built binaries
         uses: actions/download-artifact@v8

.github/workflows/test.yml

@@ -14,7 +14,7 @@ jobs:
     name: Format & lint
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v7
 
       - uses: dtolnay/rust-toolchain@stable
         with:
@@ -38,7 +38,7 @@ jobs:
         os: [ubuntu-latest, macos-latest, windows-latest]
     runs-on: ${{ matrix.os }}
     steps:
-      - uses: actions/checkout@v6
+      - uses: actions/checkout@v7
 
       - uses: dtolnay/rust-toolchain@stable
 

.github/workflows/website.yml

@@ -0,0 +1,44 @@
+name: Website
+
+# Runs on changes to the site itself. The Rust suite in test.yml is untouched
+# by a copy edit, and a broken website should be caught in review rather than
+# by a failed deploy.
+on:
+  push:
+    branches: ['**']
+    tags-ignore: ['**']
+    paths:
+      - 'website/**'
+      - '.github/workflows/website.yml'
+  pull_request:
+    paths:
+      - 'website/**'
+      - '.github/workflows/website.yml'
+
+jobs:
+  check:
+    name: Typecheck, lint, format, build
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: pnpm/setup@v2
+        with:
+          # Reads the pnpm version from the site's own package.json; the
+          # repository root has none.
+          package-json-file: website/package.json
+          install: false
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '26'
+
+      - name: Install
+        working-directory: website
+        run: pnpm install --frozen-lockfile
+
+      # Everything the deploy will do, plus the checks a deploy is a bad time
+      # to discover.
+      - name: Check
+        working-directory: website
+        run: pnpm run check

CONTRIBUTING.md

@@ -41,12 +41,29 @@ platform differences, not ordinary mistakes.
 
 ## Releases
 
-vump versions itself with vump.
+vump versions itself with vump, as two projects that ship independently.
 
 ```bash
-vump patch --through push        # or: alpha, beta, rc, release
+vump patch --project main --through push        # or: alpha, beta, rc, release
 ```
 
+| Project | Tracks | Tagged | Ships |
+| --- | --- | --- | --- |
+| `main` | `Cargo.toml`, `Cargo.lock` | `v1.2.3` | The binary: build matrix, signing, checksums, attestation, release |
+| `website` | `website/package.json` | `website-v1.2.3` | [`website/`](website) to GitHub Pages |
+
+The tag shape decides which workflow runs, and `vump check` infers the project
+from it, so neither has to be told `--project`. A copy fix on the landing page
+therefore ships without a vump version — cutting one to deploy the site would
+tell everyone pinning the binary that something changed when nothing did. The
+same separation costs the reverse: a binary release does not redeploy the site,
+so the version the page states lags until the site is released too. See
+[`website/README.md`](website/README.md).
+
+The rest of this section is about the `main` project. The website's number
+answers a narrower question — which build of the page is deployed — and needs
+none of the reasoning below, since nothing resolves it.
+
 ### Choosing the number, while the major is 0
 
 **Until 1.0, the minor is the breaking slot.** This is not a formality: Cargo

vump.toml

@@ -1,20 +1,17 @@
-# vump's own configuration.
+# Two independently-versioned projects, told apart by the shape of their tag.
 #
-# Cargo.toml is the single source of truth for this project's version: the
-# binary reads it at compile time via CARGO_PKG_VERSION, and CI verifies that
-# every released tag matches it before building or publishing anything.
-#
-# Cargo.lock records that version too, and release builds run --locked, so it
-# moves in the same commit rather than being left for a follow-up.
-
-files = ["Cargo.toml", "Cargo.lock"]
+# The binary and the website ship on their own schedules: a copy fix on the
+# landing page has nothing in it for someone running vump, and cutting a
+# release to deploy one would tell every consumer a new version exists when
+# none does. Each tag shape triggers its own workflow, and a single
+# `vump check ${{ github.ref_name }}` in CI infers which project a pushed tag
+# describes without being told --project.
 
 [git]
 # Stops short of pushing: the commit and tag are local and undoable, whereas a
-# pushed tag starts the release workflow. `--through push` when that is wanted.
+# pushed tag starts a release. `--through push` when that is wanted.
 through = "tag"
-commit_message = "chore: bump version to v{new_version}"
-tag_pattern = "v{new_version}"
+commit_message = "chore: bump {project} to v{new_version}"
 
 # Stable releases come from main, which is where every one of them has been cut.
 # The accident this prevents: merging a pull request, staying on its now-deleted
@@ -24,3 +21,20 @@ release_branches = ["main"]
 # prerelease_branches is deliberately unset. Alphas here are cut from the branch
 # doing the work — that is how every one so far has been made — and constraining
 # them would mean merging before they could be shared.
+
+# Cargo.toml is the single source of truth for the binary's version: it is read
+# at compile time via CARGO_PKG_VERSION, and CI verifies that every released tag
+# matches it before building or publishing anything. Cargo.lock records that
+# version too, and release builds run --locked, so it moves in the same commit
+# rather than being left for a follow-up.
+[[project]]
+name = "main"
+files = ["Cargo.toml", "Cargo.lock"]
+tag_pattern = "v{new_version}"
+
+# The website's version is what its deployed build reports in the corner, and
+# what `vump check` verifies a website-v* tag against before Pages is touched.
+[[project]]
+name = "website"
+files = ["website/package.json"]
+tag_pattern = "website-v{new_version}"