Awx-operator helm versioning

Hi folks,

Since the helm chart of awx-operator is now in the new repository: awx-operator-helm, we would need to potentially rethink of the versioning of the awx-operator helm chart.

Before the split, we used to have appVersion and version set to the same value in the Chart.yaml file.

appVersion is typically the version of the app that the helm chart contains while version can actually be different and somehow more independent from the app itself.

We could keep the same setup for existing versions but moving to a new versioning may present some challenges such as moving from 2.9 to 1.0. Indeed, by searching the existing helm chart versions, we can find a lot of various versions from 0.23 to 2.19.1 (latest release) and this may create some confusion. Maybe, an idea would be to start from 3.X.

What do you think?

2 Likes

I was under the assumption that they would begin using the same CalVer on everything AWX related. Whether that’s the AWX image itself, or the corresponding collection, EE, operator, and helm chart. Not to mention the AWX modules that form as they break up the monolithic structure into abstract components.

Edit: While I don’t think they’ve officially decided/announced which CalVer style they intend to use, I did suggest using YY.WW.z for year-week tags that support a SemVer z position for hotfixes released the same week. So if the helm chart had a hotfix release, but AWX itself didn’t, then perhaps this would be a good use case for having appVersion point to the AWX version and version reflect the helm chart specifically using the z position to distinguish the change. This might be easier instead of using something like YY.MM.DD which could get confusing with out-of-sync releases.

3 Likes