Rejecting unknown fields in metadata

[Gustavo Niemeyer]

On Mon, May 14, 2012 at 6:16 PM, Kapil Thangavelu
<kapil.thangavelu at canonical.com> wrote:
> Sounds good (bug: 999338). Out of curiosity what extra fields are people using,
> ie are they typos are just extraneous?

Multiple people told me they were using personal fields in metadata.yaml.

> Fwiw, there has been discussion of 3 new metadata fields for juju over the last
> few weeks.
>
>  - maintainer field

Cool, that's been agreed on regarding existence and format here in the list.

>  - category field
>  Primary purpose is For charm farm/repo user interfaces for which the current
>  flat listing is problematic at larger charm counts. This would be a controlled
>  vocabulary, and charm authors could indicate their charm matches zero or more
>  categories.

Agreed, we certainly need something like that. We need to see some
debate about how charms will be organized, how the categories look
like, and behavior changes around that field.

>  - charm api version field

Indeed, but for now we can leave that out. First, because the current
feature set may be considered as ground, and by the time we add to it
we can introduce the charm API requirement logic. Then, most
interestingly, rejecting such field is a good way to make the current
code forward compatible (it'll refuse to deploy something when we add
the new field).


gustavo @ http://niemeyer.net