typesafegithub
feat(abg): support different binding versions on different server routes
-
#1647
: 2 dependent PRs (#1624 , #1644 ) -
#1639 👈 (View in Graphite)
-
main
This stack of pull requests is managed by Graphite. Learn more about stacking.
Here a sketch how versioned routes could work, or if you like it maybe even the ready implementation. :-)
If a version is marked as deprecated, the binding classes are deprecated with a deprecation message that the binding version is deprecated. It also prints out a warning if you run it manually and additionally when run on GitHub Actions emits a GitHub Actions warning, as most often you will not see this locally due to Maven Local cached binding jar.
I would as far as possible not remove deprecated binding versions, just hint users with it to upgrade to a newer binding version.
New binding versions are by default marked experimental and issue similar warnings, with the last stable binding version in the message.
The BindingVersion can then be propagated down to the generation code where needed to generate things depending on the requested binding version.
The BindingVersion also has a property which library version should be used as dependency version that is compatible with the generated binding version, so that for example a v1 binding does not depend on a library version having a modified Step signature, or that a v2 binding does not depend on a library version that does not yet have the Expression class available.
Theoretically, we could also in the generated classes init block add a version check for compatibility, but I guess most often you will hit a compilation error before already so it will not be reached.
Then when a new binding version is added, we can add a page to the docs that documents which library version is compatible with which binding version, and which breaking changes happened from one binding version to the next, besides requiring a new library version eventually.