Thank you both — and Kevin, that's exactly the constraint I couldn't see from outside. You're right about it, and I've fixed the same hole on our own download page.
But I think I asked my question badly, because your answer settles one half of it and the half I actually care about is the other one.
Distribution to users and development are not the same problem. A forum thread is a fine way to hand someone a zip — one attachment, no ambiguity, and they can ask a question in the same place. I have no argument with that. What a forum thread cannot be is a record: there is no history to diff, no way to see what changed between two versions or why, and nothing a person arriving in three years can read to understand a decision made in 2019. That is the part I was asking about, and it survives your answer intact.
And there is a safety argument I'd make even if the record one didn't land. A Sigil plugin is code that runs on a user's machine, inside their editor, with access to their books. Today it reaches them as an attachment uploaded by an account, with no history, no review step, and no way to tell what changed since the version they had. I don't say that to cast doubt on anyone here — Doitsu's plugins are good and I've read one of them. I say it because "it has been fine so far" and "it is safe by construction" are different things, and the difference is exactly the one we insist on for ourselves: our releases are built by CI from a tagged commit, not uploaded by me, and the npm package carries a provenance attestation so anyone can check which commit produced it. We do not ship a release we have not tested. It would be strange to hold our own artefacts to that and not notice that the plugins wrapping them are held to nothing.
On the confusion problem, since you named it — I think it is a property of GitHub's release page rather than of GitHub, and it has answers that cost your users nothing. A single download page on sigil-ebook.com could name the one right file, and could pick it by the visitor's operating system without asking. Better still, Sigil could fetch from the index itself, so there is no page to visit and no wrong file to click. That last one solves your problem more completely than the forum does, and it is the reason I asked in the first place.
I'm offering that as thinking, not as a plan, and you know your users and I don't. If none of it is worth the trouble, that is a real answer and I'll take it.
Doitsu — on filenames, you have it in writing now: the eight release archives are named after the Rust target triple, they are documented, and they will not be renamed; a new target gets added alongside, never substituted. That's in
Code:
docs/INTEGRATING.md
rather than in a reply to you, on purpose — the calibre plugin and whoever comes next should read the same page instead of each getting a private assurance from me.
One thing on your side, as information rather than a request: resolving through the
list takes its first element, which includes prereleases and drafts.
excludes both. We have never published a prerelease; if we ever did, the current code would pick it and then decline to treat it as an update, because the tag doesn't parse as three integers. It fails safe, but silently.
And thank you for the offer to hand over the plugin threads — genuinely, but no. Two honest reasons. It would make us slower: there is Sigil, there is calibre, and there is whatever comes next, and a plugin per host means learning every host while the validator stops moving. And your plugins work and you maintain them; users get a better result from the person who wrote them. What I can usefully do is keep the surface underneath stable and say so in advance, and I'd be glad to help on the plugin side when I have the time — with that caveat meant honestly.