Support multiple versions of Server API bindings in a single package

[Andy-Grigg]

We currently have a 1:1 mapping between a version of the Python bindings and a version of the package, i.e. version 4.0.0 of serverapi-openapi contains the bindings for Granta MI 2024 R2.

This will be fine once Server API is stable, because the same bindings will be usable against multiple versions of MI. However, this causes problems trying to do the same now because the API is not stable. We can re-use bits of the bindings that happen to have not changed, but this is essentially a case-by-case basis.

We could resolve this by including multiple versions of the bindings in the same package, something like:

• ansys-grantami-serverapi-openapi:
  • v251 - Autogenerated code for Granta MI 2025 R1
  • v242 - ... 24R2
  • v241 - ...24R1

Things to consider:

• Do we want to have the top level import default to the latest? No obligation to do this, since every release of this package is a major release, and use of this package directly is unsupported anyway
• Do we want to re-generate all bindings or not?
  • We could leave the old bindings in place and delete when we don't want them
  • This could be problematic though if openapi-common breaking changes are introduced: The old bindings would no longer work with new openapi-common and would need to be regenerated
  • This regeneration probably wouldn't be too bad? We'd need some logic in the template to iterate through all definitions in a folder, and create separate sets of bindings for each subfolder.

[Andy-Grigg]

Anticipated that we'll need this for 2025 R2 because of ansys/grantami-recordlists#361