[Placeholder] What are the minimum required fields for the MVP release?

[prince-chrismc]

Wip because I haven't had the time to finish.

Currently there are a large number of fields that unequivocally have value but are not areas of concern for everyone.

As of the time of writing there are only 4 fields that are Marked as "Required: Yes" with 2 more as Special and Depends.

• components
• Cps_version
• name
• type

What fields can be stashed or archived to avoid complexity and can we build a complete solution with the MVP required fields.

[bretbrownjr]

While some fields are technically optional, we'll want to support them in an MVP. Off the top of my head, in addition to the required fields:

• compile_flags
• description
• default_components
• definitions
• includes
• link_flags
• version

I think that could be an incomplete list, even.

In my mind, the way to scope an MVP is to pick out which use cases should work and then support the fields needed to meet those goals. For instance, I would like to be able to describe the dependencies of cps-config on a combination of interesting platforms including Windows, MacOS, some debian family Linux, and some Red Hat family Linux. Later we could have a mode whereby cps-config can be bootstrapped and then used to support building itself. Once that works, we can add more interesting use cases and gain increasing experience until we feel the design is settled enough to justify promising not to make breaking changes in the CPS spec itself

[mwoehlke]

What fields can be stashed or archived to avoid complexity

The entire Platform object. Those bits are optional and the assumption is if they aren't present, you know what you're doing. That said, I have high confidence we're going to want something along those lines eventually, but how to represent these things is hotly debated.

The required keys are also required in the sense that we clearly have no product without them. In addition, the following are absolutely critical to any conceivable MVP:

• definitions
• includes
• link_location
• location
• requires (on Components)

In addition, I feel pretty strongly about retaining:

• all of the Requirement object
• compat_version
• compile_features
• compile_flags
• configurations (on both Packages and Components)
• cps_path
• link_features
• link_flags
• link_languages
• link_requires
• requires (on Packages)
• version
• version_schema

...and, while I wouldn't mind dropping default_components, @bretbrownjr does.

Actually, that list, with the exception of link_libraries (which there is already a request to drop; #51), is pretty much the entire current specification except for the Platform bits.

I'll actually disagree with description as being required. Strictly speaking, none of the supplemental schema is required, though I also wouldn't advocate for dropping any of it. Those fields are mainly valuable to humans, though; the expectation is that most tools can safely ignore them.

In summary, I don't think there's anything we should consider pruning except for the Platform bits and link_libraries. And the latter is already on the chopping block. (In fact, if someone wants to make a PR removing it, that would be great!)