A pre-release is a build that is allowed to be wrong. It exists so you can test a change before you commit to it, and it is named so nobody mistakes it for the final artifact. The naming is the whole discipline.
About 1 min of reading
Build a candidate and prove it is not reachable
Build an rc
Before you run it, say out loud what it will print. Then open the answer.
Ask what latest points at
Before you run it, say out loud what it will print. Then open the answer.
Compare the candidate to final
Before you run it, say out loud what it will print. Then open the answer.
Promote by rebuilding
Before you run it, say out loud what it will print. Then open the answer.
When the change touches something a consumer cannot easily test: a wire format, a database layout, a dependency's version floor. If you can test the final version in one command, skip the rc.
No pre-release artifact may be reachable from a production pointer. If latest can point at an rc, the discipline has failed and the naming is doing nothing.
1.4.0-rc1 < 1.4.0-rc2 < 1.4.0. A consumer that accepts '>=1.4.0' will not accept any rc. That is the guard that keeps a candidate out of production.
docker build -t app:v1.4.0-rc1 . puts the label on the artifact. If only the git branch says rc, the artifact in the registry looks final.
When rc2 passes, build v1.4.0 fresh. Renaming a box hides the fact that its inputs were never re-checked, and a rename is indistinguishable from a final release.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.