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.

6 Likes

I like the suggestion from @Denney-tech and advocate for CalVer style versioning.

It also seems like a good idea to make version different to appVersion so that we can start working on updates and improvements to the helm chart functionality separately to anything AWX related. So would making version a value in the format of YY.WW.z be a workable solution?

2 Likes

Hi,
imo I would prefer the 3.X.X version way, I think for people who are just discovering helm and AWX would be easier to follow, more “linear” to follow…

1 Like

@schen1 @Denney-tech @valkiriaaquatica and anyone else who wants to participate… let’s put it to a quick vote and then go for it. Please indicate your preference.

  • CalVer (YY.WW.z)
  • SemVer (3.0.0)
0 voters

I don’t use helm, so take my vote with a grain of salt. I very much would prefer consistency between all official AWX repositories. So my vote is in favor of all of them being YY.WW.z, not just the helm repository. It’s a compromise between the AWX team’s executive decision to switch from SemVer to CalVer, while retaining some of the benefit that SemVer had, even if it’s only in the zth position.

1 Like

Thanks to everyone for the votes. It looks like we’ll go with CalVer for the AWX operator helm chart.

@schen1 added a tag to the helm chart repo last week but we still need a way to map the version of the helm chart to the AWX operator version. I’ve submitted a PR that uses a text file to declare the AWX operator version: Create AWX Operator version file by oraNod · Pull Request #24 · ansible-community/awx-operator-helm · GitHub

From my own limited testing (using a local kind cluster) this seems to work. I’m open to any suggestions on improving it or different approaches.

Thanks!

1 Like

Hi again everyone,

We recently got a query about the next AWX operator helm chart release. Some good work has been done by the community and the appVersion and chart version are now cleanly separated and some other enhancements have been made to allow deployment overlays.

Anyway, while digging into the release process I noticed that Helm docs state:

“Every chart must have a version number. A version must follow the SemVer 2 standard.”

You can see that here: Helm | Charts

So… it seems likely that switching to CalVer would be adopting a convention that does not comply with what Helm enforces, which is likely to be a bad idea and lead us to some unexpected errors and headache trying to switch back.

In the interest of not breaking things, I think it might be good to stick with SemVer. I know other folks around here know this stuff better than I do so would welcome opinions and whatever insights you can share.

Please feel free to also chime in on the issue in the chart repo here: Helm chart release process · Issue #30 · ansible-community/awx-operator-helm · GitHub

Cheers.