Skip to content

release: 1.0.10 (re-ship of botched 1.0.9)#27

Merged
odanree merged 2 commits into
mainfrom
release/1.0.10
Jun 10, 2026
Merged

release: 1.0.10 (re-ship of botched 1.0.9)#27
odanree merged 2 commits into
mainfrom
release/1.0.10

Conversation

@odanree

@odanree odanree commented Jun 10, 2026

Copy link
Copy Markdown
Owner

Why this exists

Yesterday's 1.0.9 release didn't actually ship. Here's the post-mortem:

  1. PR docs: readme.txt accuracy + polish pass #25 (`docs/readme-accuracy-pass`) had the listing copy polish.
  2. PR release: 1.0.9 + fix workflow_dispatch deploy #26 (`release/1.0.9`) was stacked on top of docs: readme.txt accuracy + polish pass #25's branch — it carried the version bump to 1.0.9 plus the `deploy-to-wp-org.yml` fix for `workflow_dispatch`.
  3. PR docs: readme.txt accuracy + polish pass #25 merged into `main` first. GitHub should have auto-rebased release: 1.0.9 + fix workflow_dispatch deploy #26's base from `docs/readme-accuracy-pass` → `main`, but didn't.
  4. PR release: 1.0.9 + fix workflow_dispatch deploy #26 then merged into the soon-to-be-deleted `docs/readme-accuracy-pass` branch. When that branch was auto-deleted, the merge commit was orphaned and release: 1.0.9 + fix workflow_dispatch deploy #26's changes never reached `main`.
  5. `v1.0.9` was tagged against `main`'s HEAD (which was docs: readme.txt accuracy + polish pass #25's merge commit), so the deploy workflow shipped trunk with `Stable tag: 1.0.8` still in the readme. Both `trunk/` and `tags/1.0.9/` on SVN contain that stale Stable tag.
  6. WP.org reads `Stable tag:` from `trunk/readme.txt` to decide which tagged release to serve on the listing page. Since trunk said 1.0.8, the listing kept serving the old readme. Hence "it's been 43 minutes and the page hasn't updated."

What this PR does

  • Cherry-picks the orphaned merge commit `279f4680` from PR release: 1.0.9 + fix workflow_dispatch deploy #26 onto a fresh branch from `main`.
  • Bumps `Version:` / `Stable tag:` from 1.0.9 → 1.0.10 in `odr-image-optimizer.php` and `readme.txt`.
  • Adjusts the changelog and Upgrade Notice in `readme.txt` and `CHANGELOG.md` to point at 1.0.10 and add a one-paragraph note explaining the 1.0.9 skip.
  • No code changes vs 1.0.8.

Why bump to 1.0.10 instead of fixing 1.0.9

The `tags/1.0.9/` directory in WP.org SVN already exists with the wrong content. SVN tag deletion is discouraged in the WP.org culture and provides no value once `Stable tag` points elsewhere — the bad tag becomes inert cruft. Cleaner to ship 1.0.10 and move on.

Deploy plan

After merge:

```bash
git checkout main && git pull
git tag v1.0.10 && git push origin v1.0.10
```

Both `release.yml` and `deploy-to-wp-org.yml` fire. The deploy workflow (with the fix from this PR) reads `Stable tag:` from `readme.txt` directly, so it doesn't matter whether the trigger is a tag push or a `workflow_dispatch` — version derivation goes through one code path.

Test plan

  • Cherry-pick applied cleanly (no conflicts; `git cherry-pick 279f468` on top of current `main`).
  • `Version:` (plugin header) and `Stable tag:` (header + readme.txt) all agree at 1.0.10.
  • CHANGELOG.md `## [1.0.10]` heading matches the format `release.yml` extracts.
  • No surprise diffs vs. plain 1.0.8 + release: 1.0.9 + fix workflow_dispatch deploy #26's content — confirmed with `git diff main`.

odanree added 2 commits June 10, 2026 15:13
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.
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.
@odanree odanree merged commit 6d43f91 into main Jun 10, 2026
4 checks passed
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