Version tagging

[stackstorm]

Version tagging

[warrenvw]

@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:

Image:Tag	StackStorm Version	Description
stackstorm:dev	2.6dev	Latest 2.6dev, and most recent changes to st2-docker:master.
stackstorm:latest	2.5.0	Changes merged to st2-docker:master branch will result in a new image being deployed.
stackstorm:2.5	2.5.0	Latest 2.5.x release
stackstorm:2.5.0	2.5.0	Immutable, even if changes merged to st2-docker:master
stackstorm:2.4.1	2.4.1	Immutable, even if changes merged to st2-docker:master
stackstorm:2.4.0	2.4.0	Immutable, even if changes merged to st2-docker:master
stackstorm:2.3.2	2.3.2	Immutable, even if changes merged to st2-docker:master
stackstorm:2.3.1	2.3.1	Immutable, even if changes merged to st2-docker:master
stackstorm:2.3.0	2.3.0	Immutable, even if changes merged to st2-docker:master

[arm4b]

• For the development version, I think just stackstorm:dev would be enough as it was before and avoid overcomplication. There are usually very few reasons someone will need previous development version of stackstorm. Let's focus on most used & popular cases.
• Same for stackstorm:2.4.1.001, - looks very confusing, - I'd suggest to avoid this too and keep it simple as possible. Your approach with latest tag already solves the security/patching issue.
• I definitely like the way with major.minor version like stackstorm:2.4 pointing to 2.4.1 or 2.4.2, depending on current released StackStorm patch version 👍

[shusugmt]

@armab

Same for stackstorm:2.4.1.001, - looks very confusing, - I'd suggest to avoid this too and keep it simple as possible. Your approach with latest tag already solves the security/patching issue.

:2.5.0 and :latest(actually it is st2 2.5.0, assuming that it is the latest st2 release version at this point) will be different if there's any breaking change merged into st2-docker after the upstream release of 2.5.0 and first :2.5.0 image is out. Of course same applies to the case with security patch. Is that really

"solves the security/patching issue"

?

I 1000% agree with not having so many tags here, but :2.5.0-nnn is still needed if we apply the policy of making :2.5.0 image immutable.

[arm4b]

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 ubuntu:trusty for stackstorm), does it mean you're going to release a patch to all possible "old" and affected versions of StackStorm docker images?
Another question: do we have any real mechanism in place of tracking the security-affected software in StackStorm images and plan to go this path consistently to track/re-release new Docker image? Is it really a problem we're trying to solve?

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 latest tag in place, - that'll give you a solution and additionally encourage users to update.

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.

[shusugmt]

I get your point. Dealing with all security issues is impossible.

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 latest tag in place, - that'll give you a solution and additionally encourage users to update.

So, let me clarify this part. After we fix the tagging policy, all enhancements and fixes made against st2-docker will not available to current latest release image (:2.5.0 for example) because it's immutable after the upstream release. Those are treated as 2.6dev like other core components, and once upstream releases 2.5.1 (or 2.6.0) then all those will be included in :2.5.1. This way we can keep track of the changes in st2-docker with upstream release, and make it easier for both users and maintainers/developers to know what change was made to docker image between the st2 releases.

Am I right?

[arm4b]

Looks good to me 👍
Let's also update the table in the first message and leave it here for a while so other users will have a chance to comment on the approach before actual implementation and VERSIONING.md documentation.

[warrenvw]

I've updated the first message...

[shusugmt]

missing stackstorm:2.4 (and stackstorm:2.3 too) in table? Do we explicitly delete those tags after the release of stackstorm:2.5.0?

[warrenvw]

They're not in the table because I'd planned to enable two digit tags beginning with stackstorm:2.5. It's very unlikely we'll ever release a new release < 2.5

[shusugmt]

Ah, you are right.

We should add to description of :2.5 like something below:
Latest 2.5 release. Will not be updated (or become immutable?) after the release of new minor version (2.6.0 in this case)

[warrenvw]

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.

[shusugmt]

I see. Certainly it is possible that upstream will release 2.5.3 after 2.6.0 release.