0.0.5

What's New

Two fixes to the update flow. Both were silent — nothing logged, nothing visibly broken, just updates that never appeared or nags that never cleared.

Releases without full metadata were discarded

Release::available() required more than 5 of 8 data fields to be non-empty, which made the optional tested, requires and requires_php fields mandatory. A release carrying only version, date, download_url, download_count and body scored exactly 5, so no update was ever offered.

• available() now checks only version + download_url.
• Release::missing_meta() reports which optional fields went unresolved.
• sanitize_meta_name() strips - and + list markers, not just *, so a README Requirements section using - bullets resolves correctly.
• The Requirements heading match tolerates CRLF and trailing whitespace.
• Diagnostics are written to the debug log (under WP_DEBUG) when a release is fetched but unusable, or when metadata cannot be resolved.

The update nag survived the update

WordPress kept showing "You have version X installed. Update to X." until the next full update check.

• transient_update_plugins() only added entries, never removed them, so a response entry written before the update outlived it. Each branch now clears the entry from the opposite collection.
• A new upgrader_process_complete handler drops the memoised plugin header and the cached release payload when this plugin is the one that was updated — an admin-initiated update replaces the files and rebuilds the transient in a single request, so both caches were otherwise stale.

Upgrading: no API changes. Consumers on dev-main already have this; consumers pinned to ^0.0.4 should move to ^0.0.5.