Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(abg): support different binding versions on different server routes #1639

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Vampire
Copy link
Collaborator

@Vampire Vampire commented Sep 5, 2024

No description provided.

Copy link
Collaborator Author

Vampire commented Sep 5, 2024

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Vampire and the rest of your teammates on Graphite Graphite

Copy link
Collaborator Author

Vampire commented Sep 5, 2024

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.

@Vampire Vampire changed the title feat(abg): Support different binding versions on different server routes feat(abg): support different binding versions on different server routes Sep 5, 2024
@Vampire Vampire force-pushed the vampire/versioned-routes branch 2 times, most recently from 6aef8d4 to 6e0c383 Compare September 6, 2024 18:41
@Vampire Vampire changed the base branch from main to vampire/use-buildCodeBlock September 6, 2024 18:43
@Vampire Vampire changed the base branch from vampire/use-buildCodeBlock to main September 8, 2024 08:10
@Vampire Vampire force-pushed the vampire/versioned-routes branch 4 times, most recently from 8edd315 to 00a3375 Compare September 10, 2024 16:43
@Vampire Vampire force-pushed the vampire/versioned-routes branch 4 times, most recently from 2c8968b to e7c3171 Compare September 29, 2024 21:12
@Vampire Vampire force-pushed the vampire/versioned-routes branch 7 times, most recently from 8ae138a to 449f7e8 Compare October 30, 2024 11:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant