fix: update checker — fall back to /tags when no formal Gitea Release exists (v3.3.2)

The v3.3.0 update checker only queried Gitea's /releases/latest
endpoint, which requires a formal Release object (created via the
Gitea web UI with optional notes + zip assets attached). A plain
"git tag v3.3.x && git push --tags" from the terminal does NOT
create that Release object — so the checker kept returning "No
releases tagged on the Gitea repo yet" even when tags existed.

wp_notes_fetch_latest_release() now falls back to the
/tags?limit=1 endpoint when /releases/latest returns 404 (or any
non-200). It synthesises a release-like payload from the newest
tag — tag_name, html_url pointing at the tag view, tag message as
the body, empty assets[] so the existing download-URL logic falls
through to Gitea's source-archive URL pattern (/archive/<tag>.zip).

Net effect: the "Check now" button now finds the latest version
whether David creates formal Gitea Releases OR just pushes tags
with "git push --tags". No workflow change required.

Discovered while diagnosing why "Check now" wasn't seeing today's
v3.1.0/v3.2.0/v3.3.0/v3.3.1 tags (just pushed in this session)
— the tags were there, the formal Release objects were not.

KNOWN LIMITATION (not a bug — flagged)
The Gitea repo ranger/a-wp-notes-v3 is currently private. Anonymous
API requests get a 404 (Gitea's standard behaviour for private
repos). The updater code is correct but can't actually reach the
API on a private repo without authentication. Fix: change the
repo visibility to public on Gitea — appropriate anyway for a
GPL-licensed plugin headed for the WordPress.org marketplace.

VERSION BUMP
- wp-notes.php header 3.3.1 → 3.3.2
- WP_NOTES_VERSION constant 3.3.1 → 3.3.2
- About page version-history leads with v3.3.2; v3.3.1 demoted

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-05-25 09:29:33 +01:00
parent 3667b7a154
commit 1c93c82ef5
4 changed files with 72 additions and 13 deletions
+34
View File
@@ -9,6 +9,40 @@ Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versi
---
## [3.3.2] — 2026-05-25
### Fixed — update checker now works with tag-only workflows
The v3.3.0 update checker only queried Gitea's `/releases/latest`
endpoint, which requires a **formal Release object** (created via
the Gitea web UI with optional notes + zip assets). A plain
`git tag v3.3.x && git push --tags` from the terminal doesn't
create that Release object — so the checker kept returning *"No
releases tagged on the Gitea repo yet"* even when tags clearly
existed.
`wp_notes_fetch_latest_release()` now falls back to the
`/tags?limit=1` endpoint when `/releases/latest` returns 404 (or
any non-200). It synthesises a release-like payload from the
newest tag — `tag_name`, an `html_url` pointing at the tag view,
the tag message as the body, and an empty `assets[]` array so the
existing download-URL logic falls through to Gitea's source-archive
URL pattern (`/archive/<tag>.zip`).
**Net effect:** the "Check now" button now finds the latest version
whether David creates formal Gitea Releases OR just pushes tags
with `git push --tags`. No workflow change required.
### Known limitation (not a bug — flagged for awareness)
The Gitea repo `ranger/a-wp-notes-v3` is currently **private**.
Anonymous API requests get a 404 (Gitea's standard behaviour to
avoid leaking the existence of private repos). The updater code is
correct, but it can't actually reach the API on a private repo
without authentication. **Fix:** change the repo visibility to
public on Gitea (Settings → Visibility) — appropriate anyway for a
GPL-licensed plugin headed for the WordPress.org marketplace.
---
## [3.3.1] — 2026-05-25
**Naming: dropped the `WP` prefix. The plugin is now just `Logbook`.**