• feat(abg): add binding version v2 #1647: 2 dependent PRs (#1624,#1644)
• feat(abg): support different binding versions on different server routes #1639 👈(View in Graphite)
• main

This stack of pull requests is managed byGraphite. Learn more aboutstacking.

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.

TheBindingVersion can then be propagated down to the generation code where needed to generate things depending on the requested binding version.

TheBindingVersion 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 modifiedStep signature, or that a v2 binding does not depend on a library version that does not yet have theExpression class available.

Theoretically, we could also in the generated classesinit 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.