-
-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version tagging #78
Comments
|
? I 1000% agree with not having so many tags here, but |
Let's clarify what means "security patch" and plans about the case. Every software becomes unsync/outdated quickly. When there is a vulnerability found in any other software (say base image which is At StackStorm/st2 we're not doing any back-porting, but instead release a new version and ask users to update. Giving that you have Pragmatically speaking, it's good to think about it early, but I'd suggest to wait and time shows if you'll really need someday that additional tag suffix. |
I get your point. Dealing with all security issues is impossible.
So, let me clarify this part. After we fix the tagging policy, all enhancements and fixes made against Am I right? |
@armab No, we don't have a mechanism in place right now for tracking security vulnerabilities. We can revisit this if and when this becomes an issue. In the meantime, there's nothing stopping users from building their own image as frequently as desired, and based on a specific version of st2. @shusugmt Yes, that's my understanding. So then, summarizing the above discussion:
|
Looks good to me 👍 |
I've updated the first message... |
missing |
They're not in the table because I'd planned to enable two digit tags beginning with |
Ah, you are right. We should add to description of |
My view is that it should not become immutable. After 2.6.0 is released, it is technically possible there could be another 2.5 release... although extremely unlikely. |
I see. Certainly it is possible that upstream will release 2.5.3 after 2.6.0 release. |
We have changed the versioning semantics per #78.
We have changed the versioning semantics per StackStorm#78.
Version Tags
Problem Statement
Today, the versioning semantics of the
stackstorm/stackstorm
docker image do not meet the requirements of all users. In particular, whenever we merge changes to thest2-docker:master
branch, CircleCI builds and deploys two images to docker hub. The first image has a version tag based on the most recent git tag in thest2-docker
repo, and the second image has a version tag equal tolatest
. The problem is that the former image changes fairly regularly - which is not desired. The recommendation is that images with a semver-based version tag should be immutable.With immutable images, it is important to consider how to version security updates (or more generally, patches) to files not provided by the st2 packages. For example, if there's a security flaw in a a system library provided by the underlying OS, then it should be possible to update the image without having to wait for the next version of StackStorm.Another problem is that the nightly dev images do not have alatest
version tag, or any means of retrieving older versions of the dev image using a version tag.Proposed Solution
An image with a version tag equal to a semver (e.g.
2.5.0
) must now be immutable. A version tagequal to a two digit number (e.g.
2.5
) is always mutable and guaranteed to point at the most recent 2.5-based image. Likewise, a version tag equal tolatest
is always mutable and contains latest changes merged to thest2-docker:master
branch.If a security update/patch is required for an immutable image, we take the version tag of the immutable image and append.nnn
, wherennn
is a three digit number beginning at001
. This is done in a manner similar to that used byvim
. The two digit version tag is updated to point to this image before deploying to docker hub.We propose creating a new image namedstackstorm-dev
which always uses the latest unstable StackStorm packages. The semantics of the version tags described in the previous paragraph now apply to both thestackstorm
andstackstorm-dev
images. However, instead of using a semver to tag the nightlystackstorm-dev
image, we propose using the date instead.While it would be simpler to deploy the
stackstorm
image from only themaster
branch, at some point we may need to use a release branch. Can we get away with only branching when required? If a backward incompatible change is made to the Dockerfile, then branch so prior versions do not pick up the change.Specifying an Image
If a specific image is required, it is best to be explicit. For example:
stackstorm/stackstorm:2.5.0@{4e0e5869e784}
This way, even if the image tagged
2.5.0
ever changed, you would still get the image with the specified hash.Details
To clear up any potential confusion regarding versioning of the
stackstorm/stackstorm
image,we use the following table.
For sake of example, assume that
2.5.0
is the latest stable StackStorm version.stackstorm:dev
2.6dev
st2-docker:master
.stackstorm:latest
2.5.0
st2-docker:master
branch will result in a new image being deployed.stackstorm:2.5
2.5.0
2.5.x
releasestackstorm:2.5.0
2.5.0
st2-docker:master
stackstorm:2.4.1
2.4.1
st2-docker:master
stackstorm:2.4.0
2.4.0
st2-docker:master
stackstorm:2.3.2
2.3.2
st2-docker:master
stackstorm:2.3.1
2.3.1
st2-docker:master
stackstorm:2.3.0
2.3.0
st2-docker:master
The text was updated successfully, but these errors were encountered: