The way we build the bindings currently is rather rigid and makes it hard to be updated. As can be seen I another post (and i share the sentiment)
there is some desire to make the process more flexible and in particular, to allow for newer versions of the openapi generator images. But I also believe this is not sufficient, since updating the images brings newer templates, and our adapted templates need a way to be updated also. And all that without breaking the olde release branches of pulpcore and plugins we still need to deliver on.
In searching for a solution to this problem, we decided that we need a way to version the generator repository (and yes implicit versioning by git commits was one possibility).
However, combinatorics makes things awkward again. Not only is it unsafe to use bindings for a matching version of a plugin that were created with a different version of pulpcore, but now combining pulpcore-client and plugin clients, generated with different versions of the openapi generator is most likely to fail.
To be honestly fair, none of these problems are new. We just almost never changed the pulp-openapi-generator. And we were quite lucky to only hit the other incompatibilities on rare occasions. But continuing to do so, will wedge us in the corner and e.g. make it impossible to transition to a newer version of the OpenAPI specification which we will in turn eventually need for some features.
In conclusion what we need is a way to be able to build “stable” bindings for existing and still alive release branches, that are reasonable compatible with all installable Pulp plugin versions, to be able to innovate the whole generator process gradually and a good answer to the users question which version of the generator the right one to use for a specific installation is.
Our idea is to use a calendar based versioning scheme with an additional bugfix stream (20240725.4) and select the generator version by means of the plugin template.
Do you think, this will help? Do you have any more concerns? Please share.
In any chance you are planning to write some Pulp client tooling and are in the lucky position to be able to call into python, please consider using pulp-glue and just ignore all of the above.