Custom compatibility tags in the provider service
Metadata
Current evaluation
Feature request: add a per-application integer addendum (e.g. in AppMetadata, default 0) to the provider base compatibility_tag so charmcraft needn't override ProviderService/get_base. Open, unlabelled, tracked as CRAFT-2606.
Suggested action: keep open
Reason: Verified at HEAD (7a3a66a3) that the requested API still does not exist: ProviderService.compatibility_tag is a hardcoded property returning ".1" (craft_application/services/provider.py:97-99) and get_base composes the tag as f"{self._app.name}-{base_class.compatibility_tag}{self.compatibility_tag}" (provider.py:326) with no per-application addendum field on AppMetadata (craft_application/application.py:66-100). The only related change, merged PR #142 (commit 7df5e8a3, CRAFT-2230), added the app-name prefix but not the addendum, so the charmcraft override cited in the body is still necessary — the issue is a valid, maintainer-authored enhancement and must stay open. Impact is moderate (removes a downstream override/duplication, no user-facing bug); complexity is low since a default-zero integer field leaves existing tags unchanged and avoids invalidating managed instances (cf. the 5.6.5/5.7.1 changelog entries that bumped the tag deliberately). Confidence is not maximal because the issue leaves the field's location open ("in AppMetadata?"), so a maintainer design decision and charmcraft coordination are still needed.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
40
Quick Win:
18
Complexity:
30
Confidence:
78
Actionability:
65
|
keep open | Feature request: add a per-application integer addendum (e.g. in AppMetadata, default 0) to the provider base compatibility_tag so charmcraft needn't override ProviderService/get_base. Open, unlabelled, tracked as CRAFT-2606. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
17
Complexity:
30
Confidence:
70
Actionability:
80
|
needs triage | Feature request to allow custom compatibility tags in ProviderService via AppMetadata, avoiding the need for charmcraft to override ProviderService. Unlabelled and unassessed. | |
| qwen/qwen3.8-27b |
Impact:
35
Quick Win:
23
Staleness:
72
Complexity:
35
Confidence:
80
Support Request:
10
|
needs triage | Feature request to add a per-app compatibility tag addendum to AppMetadata so downstream apps like charmcraft need not override ProviderService.get_base. Unlabelled, no maintainer activity since 2024-03; feature still unimplemented in current code. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
85
Complexity:
20
Confidence:
75
Support Request:
10
|
needs triage | Feature request to allow custom compatibility tags in the provider service, eliminating the need for charmcraft to override internal classes. Currently unlabelled and inactive for over a year. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
20
Confidence:
80
Support Request:
10
|
needs triage | Feature request to pass a custom compatibility tag integer to the provider service, avoiding Charmcraft overrides. Unlabelled, unassessed, and inactive for over a year. |
Update history
No update history recorded yet.
Related work
-
Related To:
craft-application#142
(confidence 85%)
Merged PR (commit 7df5e8a3) made the base compatibility tag application-specific, fixing #139/CRAFT-2230, but only via the app-name prefix — it does not provide the per-app integer addendum requested here.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #142 fix(ProviderService): set base compatibilty tag | craft-application | merged | Merged PR #142 via commit 7df5e8a3, setting an application-specific ProviderService compatibility tag to fix #139 and work around craft-providers#454. |