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>
ranger
1c93c82ef5