search

StackStorm / st2chatops

Packaging environment for building StackStorm chatops native packages
Apache License 2.0
32 stars 41 forks source link

add changelog fixes #149 #180

Closed nzlosh closed 1 year ago

nzlosh commented 1 year ago

How would javascript version bumps be handled relative to an st2 versions? Are we saying that st2web and st2chatops can not be released without a version bump of st2 or that when one of these project needs to be released it'll bump st2 patch version or something like that? e.g. Release of v3.8.0

st2web-3.8.0 (v2.4.3)
st2chatops-3.8.0 (v0.8.0)
st2-3.8.0 (3.8.0)

Then there's a security patch in st2chatops that needs to be fixed so we bump the version

st2web-3.8.1 (v2.4.3)
st2chatops-3.8.1 (v.0.9.0)
st2-3.8.1 (3.8.0)

My concern with this sort of approach is that it hides what's really going on. It appears there have been changes in all packages (unintentionally there would be because of our current build process) but it doesn't reflect our actual intention. Only the st2chatops pack was intentionally changed.

From the changelog point of view, we'll have to update all 3 changelogs at the same time, how would that look when a project hasn't changed? Will there be empty sections for point releases?

Perhaps I'm missing something here or have misunderstood what is being suggested because I don't full understand the release process at this point.

arm4b commented 1 year ago

The current reality is that the CI/CD pipelines https://github.com/StackStorm/st2ci/ and https://github.com/StackStorm/st2cd/ does a release for everything. The version is monolithically hardcoded for all the components. That also affects how we build and install the packages: docker, K8s, Puppet, Ansible, Vagrant box.

Eg if there is a security patch in any of the components we release StackStorm v3.8.1 and say there's a new patch for stackstorm.

So all the time we treated StackStorm as a monolith product or a big platform as a whole.