Use RC tags
Tag release candidates with a suffix like -rc.1 so ReleaseMind can separate them.
Keep RC notes focused on risk areas and testing notes.
Keep RC notes separate
Treat each RC tag as its own draft so QA teams can track deltas.
Avoid mixing RC notes into the stable release narrative.
Promote to stable
When you are ready, create a stable tag (for example v1.3.0) and generate a new draft.
ReleaseMind will treat the stable tag as a clean boundary.
Clean up after release
Archive or label RC drafts so they are easy to find later.
Document which RC became the final stable release for audit history.
Review and introspect
RCs are most valuable when they remain distinct.
- Are RCs helping you communicate risk, or adding noise?
- Do you need a naming rule so RC tags are predictable?
- Did the stable release draft clearly supersede the RC notes?