Set a charm version from `charmcraft.yaml`
Metadata
Current evaluation
Maintainer request to accept a `version` field in charmcraft.yaml and store it in the built charm. Unimplemented: the model accepts `version` but it is hidden from the schema and unused. Blocked on design of where version lives.
Suggested action: needs triage
Reason: The issue has zero labels, zero comments, and no assignee, and the author explicitly writes it 'is blocked pending design discussions' — so it has not been assessed or prioritized by the maintainer team. The request is valid and not stale: project.py:229 still has `version: SkipJsonSchema[VersionStr | None] = None` commented 'we don't do anything with it though, so we don't show it in the schema', confirming neither half of the ask (accept/store the version) is done. Actionability is low because the core decision — root `version` file vs `metadata.yaml` vs elsewhere — is explicitly unresolved and needs a design call before code can be written; impact is moderate since this is an enhancement, not a bug, and adjacent issue #1101 was closed as infeasible.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
6
Complexity:
52
Confidence:
72
Actionability:
30
|
needs triage | Maintainer request to accept a `version` field in charmcraft.yaml and store it in the built charm. Unimplemented: the model accepts `version` but it is hidden from the schema and unused. Blocked on design of where version lives. | |
| stealth/space-bunny-alpha |
Impact:
60
Quick Win:
12
Complexity:
65
Confidence:
91
Actionability:
58
|
keep open | charmcraft.yaml’s version is already parsed but unused; design for writing it into built charms remains unresolved and blocks this valid feature request. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
11
Complexity:
40
Confidence:
60
Actionability:
60
|
needs triage | Feature request to accept a version field in charmcraft.yaml for setting charm versions. Blocked pending design discussions about where version metadata should live. | |
| qwen/qwen3.8-27b |
Impact:
50
Quick Win:
20
Staleness:
85
Complexity:
60
Confidence:
70
Support Request:
0
|
needs triage | Feature request to accept a version field in charmcraft.yaml and store it in the output charm. Open 755 days with no comments or labels; blocked on design decisions about where Juju should read the version from. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
85
Complexity:
45
Confidence:
75
Support Request:
10
|
needs triage | Feature request to accept a version field in charmcraft.yaml and embed it in the charm. Currently blocked pending design discussions, with no maintainer comments or labels after nearly two years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
50
Confidence:
80
Support Request:
10
|
needs triage | Feature request to add a version field to charmcraft.yaml for setting charm versions. Currently blocked pending design discussions, with no maintainer comments, labels, or activity in over two years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
40
Confidence:
85
Support Request:
10
|
needs triage | Feature request to add a version field to charmcraft.yaml for setting charm versions. Currently blocked pending design discussions with no maintainer comments or labels. |
Update history
No update history recorded yet.
Related work
-
Related To:
charmcraft#37
(confidence 92%)
Explicitly linked in the issue body ('Related: charmcraft#37'). #37 asked to populate the 'version' file during build and was closed pending exactly this design; authors must currently generate the file themselves, which is why const.py still whitelists it in CHARM_OPTIONAL_FILES.
-
Related To:
charmcraft#1101
(confidence 80%)
Closed as infeasible because Charmhub reads a charm's version from the built artifact, so a release-CLI version option was never added. Establishes that this issue's design must account for how Charmhub/Juju consume the version.
-
Related To:
charmcraft#358
(confidence 78%)
Closed usage question where a maintainer explained the version must be supplied in a file named 'version' — the current workaround, and the same design tension raised here about moving it into metadata.yaml.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #358 How to set the charm version? | charmcraft | closed | Usage question resolved: Charmcraft reads the charm version from a file named "version"; no code fix was needed. | |
| #1101 add a "version" option on charmcraft release cli | charmcraft | closed | Rejected: Charmhub only obtains a charm’s version from the built artifact, so Charmcraft did not add a release version option; metadata-based versioning remains separate work. | |
| #37 Populate the 'version' file as part of 'charmcraft build' | charmcraft | closed | Automatic version-file generation was rejected; maintainers directed authors to create version in their build pipeline, which Charmcraft preserves in packed charms. |