Skip to content

release: 1.0.9 + fix workflow_dispatch deploy#26

Merged
odanree merged 1 commit into
docs/readme-accuracy-passfrom
release/1.0.9
Jun 10, 2026
Merged

release: 1.0.9 + fix workflow_dispatch deploy#26
odanree merged 1 commit into
docs/readme-accuracy-passfrom
release/1.0.9

Conversation

@odanree

@odanree odanree commented Jun 10, 2026

Copy link
Copy Markdown
Owner

Summary

Stacked on top of #25. Bumps to 1.0.9 so the docs polish actually ships to WP.org via a clean tag push, and fixes the `workflow_dispatch` failure that surfaced earlier (action created `tags/refs/heads/...` because it derived the version from `GITHUB_REF` = `refs/heads/main`).

Changes

  • Version bump 1.0.8 → 1.0.9 in `odr-image-optimizer.php` (Version + Stable tag) and `readme.txt` (Stable tag).
  • Changelog entries in both `readme.txt` (`= 1.0.9 =`) and `CHANGELOG.md` (`## [1.0.9]`).
  • `= 1.0.9 =` Upgrade Notice explicitly calls it a docs-only release.
  • `deploy-to-wp-org.yml` rewritten to always parse `Stable tag:` from `readme.txt` and pass it to the 10up action as the `VERSION` env var. Works the same for `v*` tag pushes (tag → readme stable tag must agree anyway) and `workflow_dispatch` (no more bogus `refs/heads/main` derivation).

Why a release just for docs

There's no install base yet (the plugin shipped to the directory today), so we're not creating update noise. And the previous `workflow_dispatch` failure means the simplest way to actually publish the #25 readme polish is to ride along on a tag push.

Merge order

  1. Merge docs: readme.txt accuracy + polish pass #25 first (the readme accuracy pass). GitHub will auto-rebase this PR's base from `docs/readme-accuracy-pass` → `main`.
  2. Merge this PR.
  3. `git tag v1.0.9 && git push origin v1.0.9` — both `release.yml` (GitHub Release) and `deploy-to-wp-org.yml` fire.

Test plan

  • `grep -E '^Stable tag:' readme.txt | head -1 | sed -E 's/^Stable tag: *//' | tr -d '\r '` outputs `1.0.9` against the new `readme.txt`.
  • `odr-image-optimizer.php` Version + Stable tag in sync with `readme.txt` Stable tag (Plugin Check requires this).
  • CHANGELOG.md entry matches the format `release.yml` uses (`## [1.0.9] - YYYY-MM-DD`) so the auto-extracted release notes work.
  • First real validation is the tag push after merge — the workflow run page will say "Resolved Stable tag: 1.0.9" in the `Read Stable tag from readme.txt` step before handing off to the 10up action.

1.0.9 is a docs-only release that ships the listing-copy accuracy pass
from #25 plus a CI fix:

- Deploy workflow now reads 'Stable tag:' from readme.txt and passes
  it to the 10up action as VERSION. The action's default derivation
  uses GITHUB_REF, which under workflow_dispatch resolves to
  refs/heads/main and made the action try to write to
  tags/refs/heads/... — that's why the previous manual sync failed
  before committing to trunk. Reading from readme.txt works for both
  tag pushes and manual dispatches.

Plugin code is unchanged from 1.0.8.
@odanree odanree merged commit 279f468 into docs/readme-accuracy-pass Jun 10, 2026
odanree added a commit that referenced this pull request Jun 10, 2026
* release: 1.0.9 + fix workflow_dispatch deploy (#26)

1.0.9 is a docs-only release that ships the listing-copy accuracy pass
from #25 plus a CI fix:

- Deploy workflow now reads 'Stable tag:' from readme.txt and passes
  it to the 10up action as VERSION. The action's default derivation
  uses GITHUB_REF, which under workflow_dispatch resolves to
  refs/heads/main and made the action try to write to
  tags/refs/heads/... — that's why the previous manual sync failed
  before committing to trunk. Reading from readme.txt works for both
  tag pushes and manual dispatches.

Plugin code is unchanged from 1.0.8.

* release: 1.0.10 (re-ship of botched 1.0.9)

1.0.9 was tagged but never properly shipped: PR #26 (version bump +
workflow fix) was stacked on PR #25's branch and merged into that
branch instead of main. When #25's branch was auto-deleted after
merge, #26's merge commit was orphaned and never reached main. The
v1.0.9 tag was then cut against #25's merge commit, so trunk and
tags/1.0.9 both shipped with 'Stable tag: 1.0.8' inside — which is
why the listing page never updated.

This release cherry-picks the orphaned #26 commit onto main and bumps
to 1.0.10 so the readme polish + workflow fix actually go out. The
1.0.9 SVN tag stays in the directory as inert cruft; tag deletion
is non-trivial and pointless once Stable tag points away from it.

No code changes vs 1.0.8 — this is docs + CI only.
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.

1 participant