Skip to content

Say that the tags and releases are backfilled, now that they are #151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
marknolan merged 1 commit into from
Sep 17, 2026
Merged

Say that the tags and releases are backfilled, now that they are #151

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,10 +58,12 @@ so the bundle reports its own version — then tests, builds, commits and tags t
GitHub Packages and writes the GitHub release. Nothing else publishes, and it tags every time it
does.

The two drifted apart once already: `v0.1.7` (May 2026) is the last tag, while hand bumps for
vendoring carried `package.json` to `0.3.0` — so a dozen versions the consoles ran exist nowhere in
the release history. If you bump for vendoring, say in the pull request whether a release is meant to
follow.
The two drifted apart once already: tagging stopped at `v0.1.7` (May 2026) while hand bumps for
vendoring carried `package.json` to `0.3.0`, so two dozen versions the consoles ran existed nowhere in
the release history. They were backfilled on 2026-09-17 — a tag at each bump commit, a release page for
each stable one — but a backfilled tag cannot conjure a package artifact, and there is none behind any of
them. Don't let it happen again: if you bump for vendoring, say in the pull request whether a release is
meant to follow.

Roll `CHANGELOG.md` in the pull request that precedes a release: `## [Unreleased]` becomes
`## [x.y.z] - <date>` and a fresh empty `[Unreleased]` goes above it. Everything up to `0.3.0` went
Expand Down
2 changes: 1 addition & 1 deletion CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
All notable changes to `@shimmerresearch/shimmer-web-sdk` will be documented here.
This project follows [Semantic Versioning](https://semver.org/).

**On the version history below.** Only `v0.1.1`–`v0.1.7` (26 May 2026) exist as tags and GitHub releases. The only thing that publishes this package is the Cut Release workflow, and it tags every time it publishes, so nothing between `0.1.8` and `0.3.0` was ever published: those versions shipped the way the consoles actually consume the SDK, as a `package.json` bump plus a vendored `dist/` that `sync-local-sdk.ps1` copies in and stamps into each consumer's `sdk-source.json`. The sections below were reconstructed from that history — each entry sits under the first version bump at or after the commit that introduced it, dated by that bump, with the version regressions that merge ordering produced ignored — because until `v0.4.0` every entry lived in one undifferentiated `[Unreleased]` section. `v0.4.0` resumes tagged releases.
**On the version history below.** Every version from `0.1.0` now has a tag, and every stable one a release page — but most of both were backfilled on 2026-09-17. Only `v0.1.1`–`v0.1.7` (26 May 2026) were tagged at the time. Between `0.1.8` and `0.3.0` the versions shipped the way the consoles actually consume the SDK, as a `package.json` bump plus a vendored `dist/` that `sync-local-sdk.ps1` copies in and stamps into each consumer's `sdk-source.json`; the Cut Release workflow is the only thing that publishes, and it never ran for them, so their tags mark the commit that carried each version and **no package artifact exists behind them**. The sections below were reconstructed from that same history — each entry sits under the first version bump at or after the commit that introduced it, dated by that bump, with the version regressions that merge ordering produced ignored — because until `v0.4.0` every entry lived in one undifferentiated `[Unreleased]` section. `v0.4.0` resumed tagged releases, and is itself superseded by `v0.4.1`: see below.

## [Unreleased]

Expand Down