Pre-releases
Pre-releases
A pre-release is treated differently from a finished version, and this page says exactly how — and how chronik recognizes a tag as one, since a tag has no pre-release box to tick.
They are off by default
A new rule does not announce pre-releases. Switch Include pre-releases on if you want them.
The reason for the default is that a pre-release is usually addressed to a smaller audience than the
channel a rule posts into. Somebody cutting v2.0.0-rc1 is talking to the people testing it, not to
everybody watching for the next version.
What counts as a pre-release
A release is a pre-release when it is marked as one on GitHub. chronik takes that answer as it is, whatever the version is called: ticking the box is the author's decision, and un-ticking it is how a release candidate becomes the release.
A tag has no such box, so its name decides. A tag is a pre-release when a marker follows its version number directly:
7.3.0-alpha,v2.0.0-beta.2,app-v1.2.0-rc.1v7.1.0.beta1,v7.1.0.rc12.0.0rc1,2.0.0a1,2.0.0b3,2.0.0.dev1
The markers are alpha, beta, rc, pre, prerelease, preview, dev, canary, nightly,
snapshot, next, experimental and insiders, in any capitalization. The version number needs at
least one dot, so a number inside a package name, like the 3 in [email protected], is not
mistaken for one.
Every other tag counts as a finished version, including v1.2.3-1, v5.0.0-lts and a tag without a
version number. That is deliberate. A finished version held back by mistake would never reach your
channel, and nothing would tell you it was missing. A pre-release let through by mistake at least
shows up where you can see it.
When they are on, they say so
A pre-release announcement is marked as one. It is not a matter of taste: an announcement that looks like a finished version is the kind of message somebody acts on — updates a dependency, tells a customer — and finds out afterwards.
The marking appears in the message itself, so it survives being forwarded or quoted somewhere the original formatting does not follow.
Which GitHub events are involved
GitHub reports a release through several events, and they overlap:
published— a release was made visible. Fires for a normal release and for a pre-release.released— fires only when a release is published that is not a pre-release.prereleased— fires only for a pre-release.
chronik listens on published, which is the one that covers both, and reads the pre-release flag
from the release itself. That is why a release announced once stays announced once: published and
released arrive as two separate events for the same release, and a system that acted on both would
post twice.
Turning a pre-release into a release
If you publish v2.0.0-rc1 as a pre-release and later un-tick the pre-release box, GitHub sends an
edit rather than a new release. chronik updates the message that is already in the channel instead
of posting a second one — the marking disappears from the existing post.
If your rule had pre-releases switched off, nothing was posted the first time, and the release is announced normally when it stops being a pre-release.
The badge
The public changelog badge for a repository names a pre-release only if the changelog shows pre-releases, and colors it differently when it does. A badge reading a release candidate in the same color as a finished version is read as a finished version.