← Back to issue list

Set a charm version from `charmcraft.yaml`

View original Github issue

Metadata

Project
charmcraft
Number
#1790
Type
issue
State
open
Author
lengau
Labels
Created
Updated
Closed

Current evaluation

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.

Suggested action: needs triage

Reason: The issue has no labels, no comments, and no maintainer acknowledgement in 755 days, so it has never been triaged. It is a legitimate feature request (versioning charms beyond channel), but the body itself notes it is blocked pending design discussions about whether the version belongs in a root version file or metadata.yaml, so it needs a maintainer to re-evaluate whether the design question is still open before any work proceeds.

Impact: 50 Quick Win: 20.0 Staleness: 85 Complexity: 60 Confidence: 70 Support Request: 0

Issue body

### What needs to get done 1. Accept a `version` field and relevant `adopt-info` in charmcraft.yaml. 2. Store the version somewhere in the output charm. This is blocked pending design discussions. Juju currently accepts a `version` file in the root of the charm - this file is a single line text file, and whatever text is there will be presented as the version. However it sounds like we may potentially want to move this field into `metadata.yaml` or elsewhere. Related: https://github.com/canonical/charmcraft/issues/37 ### Why it needs to get done Charms should be allowed to be versioned, not just by channel.

Evaluation history

Date Model Scores Action Summary
qwen/qwen3.8-27b
Impact: 50
Quick Win: 20.0
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.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 65
Confidence: 75
Support Request: 10
needs triage Add version field support to charmcraft.yaml and adopt-info. Blocked pending design discussions on storage location, as Juju currently reads a root version file but may move the field to metadata.yaml.

Update history

No update history recorded yet.

Related work

  • Related To: charmcraft#37 (confidence 80%)

    Explicitly cross-referenced in the issue body as the related design discussion.

  • Related To: charmcraft#358 (confidence 60%)

    User question on setting charm version; closed with the answer that a root version file is used, confirming the current mechanism this feature would replace/extend.

Related issues

Issue Project State Summary Similarity
#358 How to set the charm version? charmcraft closed Closed after a maintainer explained that the charm version is set by creating a file named version containing the desired string. The user confirmed the solution, resolving the question without code changes.
79%
#669 `charmcraft` should allow setting versions for `juju status` charmcraft closed Closed as multiple topics were addressed separately. Version file generation is tracked in issue #37, while file inclusion uses parts.charm.prime in charmcraft.yaml. The development workflow documentation update was opened as issue #695. No direct fix implemented here.
75%
#37 Populate the 'version' file as part of 'charmcraft build' charmcraft closed Rejected. The team decided against auto-generating a version file due to evolving Juju/Charmhub versioning semantics. Developers must create the file in their build pipeline; charmcraft preserves existing version files during packaging.
73%
#1101 add a "version" option on charmcraft release cli charmcraft closed Rejected. The store determines version from the artifact itself, not CLI input. Dynamic version extraction from charm metadata is under separate consideration.
72%