Deprecating implicit series support for charm-build

Is there any reason not to deprecate implicit series support, i.e. defining what series a charm supports solely by how it is uploaded to the store, in charm build, in favor of explicitly defining the supported series in the charm’s metadata.yaml? The latter can handle single or multi-series charms and has been available (and I believe recommended) for some time, but charm build still tries to make guesses about the series when it can’t be determined. And it seems that the more common reason for not being determined (at least in my experience) is due to trying to build from an invalid directory. I think that failing fast in this case would be a better overall user experience.

If there are no objections, I’d like to introduce a deprecation warning with the next release of the charm snap, and make it fatal (perhaps with an override flag) on the subsequent release.

1 Like

Big +1 from me. The implicit series support is totally obsoleted by the explicit (multi) series declaration in charm metadata. We really want all charms to be multi-series where possible.

1 Like

I’ve gone forward with the implicit series deprecation, as well as taking the chance to improve some of the environment variable and CLI flags used by charm build as well as making the output directory a bit more consistent and predictable, in charm-tools PR #478. Feedback / discussion is welcome either here or on the PR.

1 Like

Thanks Cory that’s a nice win for sensible defaults and UX.