Charm Interface Versioning and Collaboration

Continuing the discussion from Charms for centos - lets begin:


Including @cory_fu.

We could almost use like a “package manager” for interfaces. A public place where people could register names and indicate the stability of the interface definition, similar to semantic versioning.

So if I want to design an interface, I create a doc or spec of some sort, however we standardize on that, and I push it to the interface store under an available name. First I push it with the 0.1 version, which clearly indicates that it is unstable and subject to chang until it hits version 1.0 at which point it should get no breaking changes until version 2.0.

Now I technically “own” that interface, but similar to packages on Crates.io you can transfer ownership and allocate that to a team or organization. Also the interface is probably backed by an Open Source interface definition, which allows people to make pull requests to it.

If the existing interface doesn’t fit my needs, then I can either contribute or I can create a new interface to facilitate the need. Yes that could lead to fragmenting the community because, “well your interface doesn’t do what I need and I want a different PostgreSQL interface” or something like that leading to multiple incompatible standards, but you don’t get away from that by having an informal standard that you don’t necessarily have to follow anyway. All that does is leave it more likely that connecting different charms will break.

Anyway, that’s just some brainstorming.