Repository navigation
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
The focused change preserves exact-ID precedence, consistently updates both delivery paths, and has no unresolved review findings.
No open issues 🎉
What changed in this PR
Adds version-wide extension configuration through .v* keys while preserving exact-ID precedence. Both in-process and executable extensions use the shared lookup behavior.
Changes:
- Adds configuration-key validation and exact-first lookup with
.v*fallback. - Integrates lookup into broker initialization and launcher startup.
- Documents wildcard configuration and tests validation, precedence, and matching.
| File | Description |
|---|---|
| internal/launcher/launcher.go | Uses shared configuration lookup for the startup handshake. |
| internal/broker/broker.go | Uses shared configuration lookup during extension initialization. |
| host/host.go | Documents wildcard keys and exact-ID precedence. |
| docs/DESIGN.md | Explains configuration sharing across extension versions. |
| docs/AUTHORING.md | Adds wildcard examples and configuration guidance. |
| core.go | Adds key validation and version-aware configuration lookup. |
| core_test.go | Tests key validation and configuration selection. |
Review effort: Balanced
An id like org.example.v1.v2 was valid, with org.example.v1 as its name. That name is also a valid extension id, so the two can't be told apart. ValidateExtensionID now rejects ids whose name ends in a version. Ids are checked segment by segment instead of with a regular expression. Signed-off-by: Paweł Gronowski <git@grono.dev>
Config was looked up only by the exact extension id, so config for org.example.foo.v1 did not apply to org.example.foo.v2. A config key can now leave out the version, like org.example.foo, to apply to all versions. A key with the full id still wins. Only the last version is dropped, so org.example.foo does not match org.example.foo.runtime.v1. Signed-off-by: Paweł Gronowski <git@grono.dev>
ce5f7ac to
77e8df1
Compare
| A key without the version, such as `com.example.other`, applies to every version of that extension. | ||
| It matches only that name: `com.example.other` does not reach `com.example.other.runtime.v1`. | ||
| A key with the full id, such as `com.example.other.v2`, takes precedence over it. | ||
| Because each version is a separate extension, a versionless entry must suit the configuration format of every version it reaches. |
There was a problem hiding this comment.
So, having (e.g.) both com.example.other.runtime.v1 and com.example.other.runtime makes one config apply to v1, and the other for com.example.other.runtime.v0, com.example.other.runtime.v2, com.example.other.runtime.v3 (any other version), right?
Probably works, yes; alternative could be to not allow a mix of versioned and non-versioned for the same match. (Not sure if that's better/clearer though).
Mostly thinking there if there's situations where I would have multiple versions of the same extension installed (could we come up with reasons for that? do we / do we want to allow that?)
There was a problem hiding this comment.
I don't think there's a reason to allow multiple versions of the same extension running at the same time.
For mixing.. I'm thinking if it would make sense to merge them - so the "versionless" kinda acts as a base, and then the per version can adjust it. But I don't think we should do it now.
Config was looked up only by the exact extension id, so config for org.example.foo.v1 did not apply to org.example.foo.v2.
A config key can now leave out the version, like org.example.foo, to apply to all versions.
A key with the full id still wins.
Only the last version is dropped, so org.example.foo does not match org.example.foo.runtime.v1.