# Streamlining AWX Releases

**URL:** <https://forum.ansible.com/t/streamlining-awx-releases/6894>\
**Category:** Project Discussions\
**Tags:** community, awx-operator, mindshare, awx-modernization, release, awx\
**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:** 4

<div class="post-metadata">

**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\
**Post date:** [July 2, 2024, 9:58am UTC](https://forum.ansible.com/t/streamlining-awx-releases/6894/4 "2024-07-02T09:58:02Z")

</div>

> [@ericzolf](#):
>
> I would suggest to have a look at [Conventional Commits](https://www.conventionalcommits.org/). In my experience with my own project and with customers, it becomes the responsibility of each author and reviewer to make sure that each merge request/commit has the necessary information, but then it becomes [easy to programmatically extract](https://github.com/rdiff-backup/rdiff-backup/blob/master/tools/get_changelog_since.sh) the necessary information from the git log.

Thanks for those links.

In AWX we currently use the PR description to define what type of change this is, the following is from the AWX release process.

PR descriptions contain: `Bug, Docs Fix or other nominal change` or `New or Enhanced Feature`

```auto
Getting current versions
    awx: 24.3.1
    awx-operator: 2.16.1
PR https://github.com/ansible/awx/pull/15196 votes z
...
PR https://github.com/ansible/awx/pull/15150 votes y
PR https://github.com/ansible/awx/pull/15191 votes z
https://github.com/ansible/awx/compare/24.3.1...devel
awx devel is 13 commit(s) ahead of release 24.3.1

All commits voted, the release type suggestion is y

```

What I’m not sure is how that gets represented in the CalVer schema.

---

_[View the full topic](https://forum.ansible.com/t/streamlining-awx-releases/6894)._