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:
@@ -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`.**
|
||||
|
||||
Reference in New Issue
Block a user