Awx: Versioning strategy for AWX vs. Tower?

[geerlingguy]

Summary

Using the Fedora:Red Hat Enterprise Linux analogy mentioned in the AWX FAQ, versioning seems like it will not (according to the response in #31) be 1:1 between AWX and Tower.

So, Fedora can release 23, 24, 25, 26, etc. while Red Hat stays on 7, then eventually 8.

In a similar way, AWX can go 1.0.0, 1.1.0, 2.0.0, etc. while Tower is following it's own separate release cycle/tagging convention.

_However_, there are some bits of code in the AWX codebase that currently refer to Tower's versioning scheme, e.g. https://github.com/ansible/awx/blob/bfea00f6dc6af0fb01057ce38e9d0337e6c589aa/awx/api/generics.py#L179-L190

Is there any way we could abstract out these Tower-version-specific things in the codebase?

Environment

N/A

Steps To Reproduce:

N/A

Expected Results:

N/A

Actual Results:

N/A

Additional Information:

N/A

[matburt]

Yep we can totally rework this to support the parallel version strategy, just need to take a look at the best way to do it.

[hogarthj]

It would be useful to have something showing a rough mapping at least so that users referring to http://docs.ansible.com/ can have an idea of what is upstream here right now and what they can translate to their commercially supported install... and for contributors to get a better idea when their code in AWX has filtered down to their commercially supported installs.

[wenottingham]

I can understand that. I will note that currently AWX is "later" than Tower 3.2

[ryanpetrello]

The way we're doing this _now_ will not scale for awx + Tower; defining special variables in the Python source tree for _every_ API view is simply too much manual work for people to track and curate as the API expands.

I think the best way to power this would be in an automated fashion via our new Swagger doc generation: https://github.com/ansible/awx/blob/devel/CONTRIBUTING.md#building-api-documentation

Now that we have an automated way to produce OpenAPI documentation for the REST API, one way to solve this might be:

1. Have an automated process that builds the OpenAPI spec every time we make an awx release and uploads the JSON artifact to a well known address (indexed by git tag).
2. Write a small bit of Python that can fetch two tags, parse the API paths and methods defined in both JSON files, and generate a changelog that describes "what changed" between the two versions.

[matburt]

I'm going to close this as we'll be able to track this on the documentation side soon and that's about as good as we are going to get in the near term.