# 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:** 15
**Author:** ![utoddl](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/utoddl/32/249_2.png) [@utoddl](https://forum.ansible.com/u/utoddl)\ **Post date:** [July 6, 2024, 12:54pm UTC](https://forum.ansible.com/t/streamlining-awx-releases/6894/15 "2024-07-06T12:54:24Z")
I understand you have to have some uniquifying string to identify a particular release, whether SemVer, CalVer, CodeName, or something else. I probably prefer CalVer if only because it gives a feel for how old different components of a software stack are _relative to one another_. Comparing projects with different release cadences is apples and oranges, but at least with CalVer you’re _comparing all your apples to the same orange_. Otherwise – to me – they are just strings. But the point I want to make is this: Just because you switch to CalVer for naming releases doesn’t mean you have to throw out SemVer and its benefits ([see @mariolenz’s post #13 above](http://forum.ansible.com/t/streamlining-awx-releases/6894/13)). A line in the release notes saying “This _YYYY.MM.DD_ release corresponds to SemVer _X.Y.Z_” would be enough. Or a line in a meta.yml file like ``` semver: x.y.z ``` would suffice, wouldn’t break anything, and still provides the kind of information people use to make SemVer-based decisions. --- _[View the full topic](https://forum.ansible.com/t/streamlining-awx-releases/6894)._