# Streamlining AWX Releases **URL:** \ **Category:** Project Discussions\ **Tags:** community, awx-operator, mindshare, awx-modernization, awx, release\ **Created:** [July 1, 2024, 3:20pm UTC](https://forum.ansible.com/t/streamlining-awx-releases/6894 "2024-07-01T15:20:58Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\ **Post date:** [July 2, 2024, 6:28pm UTC](https://forum.ansible.com/t/streamlining-awx-releases/6894/7 "2024-07-02T18:28:55Z")
There’s a lot to digest here, and I have a lot of ideas to share. I’m going to try and stay on topic here while I share my feedback. > [@gundalow](#): > > AWX has always been a “one-way street” - no stable/release branches… While I don’t expect AWX to support “stable” release branches, I’ve always been annoyed that there’s no reference point for what AWX version/commit matches what Ansible Controller version downstream. Even with the understanding that AAP will apply changes to its AWX fork downstream, it would still be nice to know from which commit AWX was forked from. Creating an “aap-x.y” branch in AWX for subsequent AAP releases would be welcome. It might even be useful to your internal team if you needed to back-port fixes applied upstream instead of cherry picking them after the fact. > [@gundalow](#): > > As we’ve started socializing this idea, one FAQ has been how we will be denoting and communicating breaking changes. This and some other things we don’t know yet are captured a little further down. What we do know, is that release notes will continue to be auto-generated from Pull Request titles. We will also be engaging the community as we begin to make changes to our tooling to look into possible ways of programmatically detecting or automating this. So there’s a few different things around “breaking changes” and release cycles I want to talk about. > **Code deprecation/breaking design changes** > > These things should fit somehow into your normal release and announcement workflows. Whether or not deprecations should be given a specific support period before fully removing them is another topic. > **Releases with unintended breaking changes** > > Things like the awx-operator deleting the wrong PVC or in the wrong order of operations for things like postgresql upgrades, or changes that otherwise prevent parts or all of AWX from working as expected. Particularly borked releases need a process for purging all related tagged images (not just the main culprit images, but things like operator bundle/catalogs/etc). As well as integrating with the regular announcement workflow to notify users of known issues, removal of these images, and whether or not to expect a hotifx or wait for the next release cadence. > **CICD is a must** > > Having some level of CICD built around addressing breaking changes is definitely a must after you switch to CalVer. With SemVer, if x.y.0 introduces breaking changes, they may get fixed in x.y.1, so as a general rule, it’s safe for consumers (users) to assume that a given z version should be skipped if there’s any subsequent z version. Hotfixes could be released even the same day. I’m not sure how same-day-hotfixes would look in CalVer, but regardless of what that tag looks like, it might make sense to remove images with breaking changes altogether (whether that’s the main image, the operator, or the operator’s catalog/bundle/manfests/etc). If “bad” images are removed, there’s less concern (for us users) about using the ones that remain. > **PS about awx-operator-catalog** > > Additionally, the awx-operator-catalog could be improved with more detailed entries, replaces, and skips/skipsRange that exclude the broken images, but only if that can easily be automated (I do this easily enough for SemVer, but CalVer might be a headache). > > The operator catalog release cycle itself is something else to think about. As it is right now if you switch to weekly/nightly releases, every release would throw PR’s at the community catalogs, upstream and downstream. I don’t know how automated or noisy that might be. > [@gundalow](#): > > # What we don’t know yet > > - Should we use `YY.MM.DD` or `YYYY.MM.DD` `YYYY.MM.DD` for sure. ~~Including leading 0’s as @eburgueno suggested.~~ Edit: I’m actually thinking maybe without leading 0’s to keep the CalVer consistent with SemVer enough to allow “version type” tooling to continue working as expected. Maybe even doing weekly release versions with incremental z version for out-of-cycle patches, i.e: `YYYY.WW.0` `YYYY.WW.1` > [@gundalow](#): > > - How breaking changes will be communicated as we move from SemVer to CalVer. Make posts to all the usual release announcement mediums notifying the breaking changes, presenting any disaster-recovery processes if applicable (like that PVC deletion one a few months ago), and purging those particularly broken images from Quay. > [@gundalow](#): > > - At what cadence AWX will be released. We are currently considering nightly builds, or perhaps weekly snapshots. Maybe at most a weekly release cadence (Mondays? So hotfixes can be applied quickly during the work week if needed), and a separate `nightly` tag for nightly builds if they are desired. --- _[View the full topic](https://forum.ansible.com/t/streamlining-awx-releases/6894)._