You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we are using the latest Docker tag to represent both stable and unstable builds from our main branch. This is counter to the common practice in Docker workflows, where the latest tag is usually reserved for the most recent stable release. This current usage can potentially confuse users and lead to inadvertent use of unstable builds when a stable build is expected.
Proposed solution
To resolve this issue, we propose adjusting our Docker tagging strategy as follows:
Use the latest tag only for the latest stable releases. This follows common Docker practices and will make it clear for users that they are getting a stable version of the software.
Continue using specific version tags (e.g., v0.X) for each stable release to allow users to pull specific versions if required.
Introduce a new Docker tag (e.g., next, unstable, dev) for the most recent main branch commits. This will provide an option for users who wish to use or test the latest changes in our software, even if these changes haven't been officially released.
By implementing this tagging strategy, we can provide clear expectations about the stability and freshness of the software represented by each Docker image.
The text was updated successfully, but these errors were encountered:
Tag `latest` Docker images to the latest git tag.
Also tag `next` Docker images to the latest commit on `main.
Previously, we tagged `latest` to latest commit on `main` only.
category: misc
ticket: #2359Closes#2359
Problem to be solved
Currently, we are using the
latest
Docker tag to represent both stable and unstable builds from ourmain
branch. This is counter to the common practice in Docker workflows, where thelatest
tag is usually reserved for the most recent stable release. This current usage can potentially confuse users and lead to inadvertent use of unstable builds when a stable build is expected.Proposed solution
To resolve this issue, we propose adjusting our Docker tagging strategy as follows:
Use the
latest
tag only for the latest stable releases. This follows common Docker practices and will make it clear for users that they are getting a stable version of the software.Continue using specific version tags (e.g.,
v0.X
) for each stable release to allow users to pull specific versions if required.Introduce a new Docker tag (e.g.,
next
,unstable
,dev
) for the most recent main branch commits. This will provide an option for users who wish to use or test the latest changes in our software, even if these changes haven't been officially released.By implementing this tagging strategy, we can provide clear expectations about the stability and freshness of the software represented by each Docker image.
The text was updated successfully, but these errors were encountered: