min-juju-version is proposed for deprecation - what’s proposed to replace it?
The functionality of min-juju-version should be replaced with assumes, which is in the process of being specced out.
It’s currently not supported in Juju, if this is a publisher-only field, we still should add it to the Juju metadata to ensure that we capture it and can utilize it as well.
So juju itself never utilized display-name, it was there for consumption by the Charm Store to be able to diverge the title-on-the-page from the title that you deploy. (eg, ‘MySQL’ vs ‘mysql’ at the very least).
I believe that Charmhub has actually been moving in a different direction, where store-only data is not read from the charm metadata.yaml but instead is editable on the website. (go to https://charmhub.io/<your-charm>/listing and you can see the attributes that you can edit.)
This is also the expected route to go for things like charm categories, and other such properties that only really apply to the store, rather than the charm itself.
It also is a cleaner model when you start thinking about multiple channels for a charm. Once you have 4 different binary .charm files published, which one of them is the canonical ‘display-name’, and which one has the right categories, etc.
Hello! What is this field for? Where it will be used? Is it ok to put the original author here?
I’m asking this questions because there is a request for Charmcraft to automatic populate this field when a charm is initiated, but we’re not sure if that is fine, in which format this should happen (as we don’t know how this is planned to use), etc.
Thanks!!
We have been using this in our charms:
maintainers:
- John Doe <john@doe.com>
- Jane Doe <jane@doe.com>
Similar to one of the examples above. But, should it also support adding a team to the list?
What is the difference between tags and categories in the charm metadata.yaml? Which one should we use to make our charms easily searched in CharmHub?
I’ve taken the YAML-style spec from my previous post and made it into a docs page, let’s please use that as the source of documentation for the metadata spec going forward, as it’s a little more discoverable and easy for developers to re-use: Juju | Charm Metadata Reference
1 Like