The release-status page said no release was tagged (#383 follow-up)

[jdatcmd]

Follow-up to #383, which pointed the README at 1.0-alpha.

The status badge two lines above the one #383 edited links to docs/limitations.md#release-status, and that section still read:

The version marker is 1.0-dev, recorded in VERSION, and there has been no tagged release.

Both halves were wrong after v1.0-alpha shipped, and the second is the one that matters: a reader following the badge from a README that says 1.0-alpha landed on a page telling them no release exists.

The guidance below it is unchanged, because it is still true of an alpha: reloadable tables, appropriate for evaluation and analytical rebuilds, not yet a production system of record. Only the "until there is" premise, which assumed no release existed, is reworded.

Deliberately not restating the extension's default_version here. #389 moves it to 1.0-alpha with an upgrade script, so a paragraph pinning it at 1.0-dev would be false on merge. The CHANGELOG already carries that distinction.

Docs only.

🤖 Generated with Claude Code

[ChronicallyJD]

Approved. Correct, and a gap I left in #383.

I fixed the badge and the prose in #383 and did not follow the badge's own link, which is
where the contradiction actually landed. Verified the claim rather than taking it:

tag=v1.0-alpha prerelease=true draft=false published=2026-08-04T17:59:47Z

So "tagged and published as a pre-release" is exact, and keeping the guidance below it
unchanged is right. An alpha does not change what you should do with the data.

The same file says it again, 85 lines down, and that copy is dangerous

Sweeping for the rest of the claim, docs/limitations.md still has this, untouched by
this PR:

The pre-release ships no ALTER EXTENSION UPDATE scripts, so there is no in-place
catalog migration either.

You can replace the shared library and the SQL script, and then restart, without a
new CREATE EXTENSION.

Across an incompatible build, recreate the extension with DROP EXTENSION and ...

Three problems, in increasing order of how much they matter:

1. The first sentence becomes false when #389 merges. It ships exactly one such script.
2. The bolded sentence is the precise sequence that breaks an install under #389.
   It is the same wrong instruction I found in docs/installation.md and rewrote there.
   I did not sweep for a second copy, and this is it.
3. It then sends the reader to DROP EXTENSION, which is the thing you flagged on #389 as
   taking their tables with them.

So a user who hits the broken state, follows the badge, and reads down this page is told
the recovery that loses their data, on a page that has just told them no migration exists.

Suggestion

Merge this as-is. It fixes what it claims to fix and it is correct.

I will carry the upgrade paragraph in #389, since #389 is what falsifies it and already
carries the docs/installation.md rewrite and the changelog entry. Keeping all three
upgrade edits in the PR that causes the change means they cannot land out of order.

Shout if you would rather it came here instead.