Using tags like `-BETA` or `-RC` is a common practice in software development to indicate the stability and readiness of a release. Here’s a breakdown of what they mean and when to use them.

Using tags like -BETA or -RC is a common practice in software development to indicate the stability and readiness of a release. Here’s a breakdown of what they mean and when to use them.

What They Are

  • BETA: A beta release is a version of your software that is feature-complete but not yet stable. It’s released to a limited audience for testing and to gather feedback on functionality and bugs. A beta version is generally expected to have bugs and may have some performance issues. The primary goal of a beta release is to find and fix major issues before the final production release.

  • RC (Release Candidate): A release candidate is a version of the software that is considered potentially stable enough for production. It has passed all internal testing and is now being released for final verification. An RC version should have no known bugs and is expected to become the final release unless a critical issue is discovered during this final round of testing.

How to Use Them

This tagging strategy fits perfectly within the Gitflow model you’re using.

  • During a Release Cycle: When you create a new release/x.x.x branch, you can tag your Docker images with -BETA to indicate that it’s a new version under active testing. For example, my-app:1.1.0-BETA.

  • Before Final Release: Once the code on the release/x.x.x branch is stable and you believe it’s ready for production, you would tag the next build as an -RC. This is the last step before the final release. For example, my-app:1.1.0-RC. If a critical bug is found, you can create my-app:1.1.0-RC.2 to indicate a second release candidate.

  • Final Release: When the RC build is approved and merged into your production branch, you would remove the -RC suffix and tag the final image with the clean version number, like my-app:1.1.0.

Summary

Tag Stage Purpose
BETA Feature-complete but unstable For broad testing and feedback; bugs are expected.
RC Final testing and verification A candidate for the final release; bugs are not expected.
Final Release Production The stable, approved version ready for public use.

Using these tags provides clarity and helps your team and users understand the stability of a given version, preventing unstable code from being mistaken for a production-ready release.