Skip to content

Stop naming a release version outside the changelog - #36

Merged
sehkone merged 1 commit into
mainfrom
sehkone/issue-34
Aug 8, 2026
Merged

Stop naming a release version outside the changelog#36
sehkone merged 1 commit into
mainfrom
sehkone/issue-34

Conversation

@sehkone

@sehkone sehkone commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

Closes #34.

Four places named 0.1.0 without pinning anything. Each would have read as stale the moment 0.2.0 shipped, and two of them were user-facing.

Place Treatment Why
samples/*/docs/theme.toml 0.0.0 + comment inert — install-samples.sh always installs with --source, so version never resolves anything
README docs/theme.toml example <version> + link to releases a reader must substitute a real version, so 0.0.0 would be wrong guidance
scripts/fetch-theme.sh header comment and SAMPLE_CONFIG <version> same as the README — SAMPLE_CONFIG is what a consumer sees when their theme.toml is malformed
tests/{installer,pdf}-test.sh fixtures 1.2.3 the release test stubs gh and copies a local tarball, so 0.1.0 implied a dependency on a release that the test never fetches

<version> matches what the README's "Publishing a New Release" section already uses, for the same stated reason — so the example cannot go stale again.

Scope note

The issue described the samples and the README. The two fetch-theme.sh examples and the test fixtures turned up while checking the issue's own acceptance criterion — that no file outside CHANGELOG.md names a specific release — and are the same defect, so they are fixed here rather than left for a follow-up. Say the word if you would rather see the script and tests split out.

No CHANGELOG.md entry. fetch-theme.sh is release-surface, so this technically changes it, but the change is a placeholder inside a comment and an error message: nothing a consumer's reviewer triages, which is what that file says its sections are for. Happy to add a ### scripts line if you would rather it be recorded.

Verification

  • tests/installer-test.sh and tests/pdf-test.sh both pass — the fixture rename is consistent across write_config defaults and every assertion that greps the installer's output.
  • shellcheck clean on scripts/*.sh and tests/*.sh.
  • Both samples build with --strict; install-samples.sh --force installs and records version = "0.0.0", source = "local" in .meta.
  • markdownlint-cli2 passes; README stays within 80 columns.
  • grep for 0.1.0 across the tree returns nothing outside CHANGELOG.md, which is the issue's acceptance criterion.

Four places named 0.1.0 without pinning anything, and each would have
read as stale the moment 0.2.0 shipped.

The sample configs are inert: install-samples.sh always installs with
--source, so version never resolves anything. They get 0.0.0 and a
comment saying why the value is deliberately not kept in step with the
tags.

The README example and the two examples inside fetch-theme.sh — its
header comment and the sample config its error messages print — are
documentation a reader copies, so 0.0.0 would be wrong guidance there.
They get a <version> placeholder, matching what the release section of
the README already does for the same reason.

The test fixtures stub gh and never download, so 0.1.0 suggested a
dependency on a real release that does not exist. They get 1.2.3, which
cannot be read as anything but an arbitrary value.

Closes #34
@sehkone
sehkone merged commit 5f3b714 into main Aug 8, 2026
6 checks passed
@sehkone
sehkone deleted the sehkone/issue-34 branch August 8, 2026 05:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Stop naming release versions in places that are not real pins

1 participant