110 - Adopt plugin versioning scheme#110
Open
robobario wants to merge 1 commit into
Open
Conversation
Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Robert Young <robertyoungnz@gmail.com>
robobario
force-pushed
the
explicit-plugin-versioning
branch
from
1e30107 to
0622ff2
Compare
7 tasks
Member
Author
|
Prototype implementation kroxylicious/kroxylicious#3952 |
robobario
changed the title
Open
robobario
commented
May 14, 2026
| For proxy users, configuration syntax extends from `type: RecordEncryption` to support `type: RecordEncryption/v1alpha1`. | ||
| When a version is present in the type string, the proxy uses it both for validation and for name resolution. | ||
| A plugin named RecordEncryption annotated with `@Version("v1alpha1")` can be referenced as either `RecordEncryption/v1alpha1` (explicit version) or `RecordEncryption` (implicit, triggers warning). | ||
| If multiple RecordEncryption implementations exist with different versions (v1alpha1 and v1beta1), users disambiguate by including the version rather than switching to fully qualified class names. |
Member
Author
There was a problem hiding this comment.
that should say can disambiguate it's optional and they could still disambiguate using fully qualified name, backwards compat is preserved in phase 1.0.0
robobario
commented
May 14, 2026
| Kroxylicious is approaching its 1.0.0 release, which will establish backward compatibility guarantees for public APIs. | ||
| However, different plugins may have different maturity levels and API stability guarantees. | ||
| Coupling all plugin APIs to a single project version creates tension between shipping experimental features and maintaining stability. | ||
| The Record Encryption filter, for example, may need multiple major revisions before its API stabilizes, but tying those revisions to the project version would either delay 1.0.0 or force premature API commitments. |
Member
Author
There was a problem hiding this comment.
claude has picked our most stable plugin for the example 🤷
robobario
commented
May 14, 2026
|
|
||
| Phase 2 begins with the 1.0.0 release. | ||
|
|
||
| - The enforcement policy changes from warning to error when a plugin declares a version but the configuration omits it. |
Member
Author
There was a problem hiding this comment.
needs a bullet to say that the annotation on the plugin becomes mandatory too
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a smaller idea for adopting plugin versioning without tackling all of the other ideas like contract-first Configuration based on JSON schemas, kubernetes sympathy by decomposing into multiple configuration files which are covered in #96 . It only makes versioning explicit and adopts k8s CRD versioning conventions to try and make our stability guarantees explicit.
Proposal generated with the help of Claude Sonnet 4.5