compose-spec
Process for spec changes?
Should we define a spec change process like the Python PEPs https://www.python.org/dev/peps/?
I am wondering how we will version the spec or test conformity. Checking by which enhancements are implemented is one way that works quite well.
It's not easy to follow the pep process in github issues/PRs. But we do need some more formal spec change process.
TUF has a separate repo for the pep equivalent https://github.com/theupdateframework/taps as part of their workflow. Probably other ways to organize we can look at for specs.
I'm used with this approach from my previous work on https://github.com/jenkinsci/jep. I suggest we adopt something comparable but keep it light
I also would like we define some generic approval rules to keep the spec generic, i.e: "new fields can only be introduced in the Compose file format if they are implemented by at least 2 vendors, and implemented (or, at least, mocked) by the reference implementation". This would prevent to get proposals for vendor-specific attributes that only make sense on a single Platform.
