I'm on board with what's proposed here.

It was mentioned in the discussion yesterday, and I believe nobody
objected, but just to be explicit again, it would be nice to reuse field
names, types, and semantics across these metadata files (such as the module
scanning response file) whenever possible, in order to avoid accidental
complexity to the C++ ecosystem as a whole.

And, a small design concern:

I do wonder how we make a breaking change and a major version update to the
schema without using a new filename. At the scale of use of standard
library implementations, seems like the same file basename will need to
represent the old and new schemas at the same time, assuming an at least
somewhat gradual transition as the breaking change is deployed and adopted.

Possibly the query and response to the toolchain to locate the metadata
file needs to include what schema version is expected? Or perhaps the
toolchain should be allowed to provide a set of metadata files that a
consumer can attempt to parse. Though both of these approaches might work
better for specifically the std module and less well for modules the
toolchain does not have awareness of.

Bret

On Wed, Dec 13, 2023, 08:23 Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:

>
>
> On Wed, Dec 13, 2023, 02:36 Iain Sandoe via SG15 <sg15_at_[hidden]>
> wrote:
>
>> - A "current version" and a “minimum supported version", which means
>> that this manifest would be a correct representation for a tool supporting
>> “minimum supported version” (but might have some improved capability for
>> later tools, supporting "current version").
>>
>
> The version in this case refers to the version of the schema.
>
> That should indicate what fields are expected to be present, which fields
> are optional, and what is the semantics of those fields
>
> - A clear rule that says how a tool supporting minimum but not current is
>> to skip the data it does not recognise (and a mechanism for organising
>> content that allows this).
>>
>
> The general expectation, as we discussed on the context of compatibility
> for the Ecosystem IS, is that if the file has a new revision on the same
> version, a tool that knows about an older revision should be able to parse
> that file with the correct semantics while ignoring the fields it doesn't
> know about.
>
> That limits what kinds of changes can be done to the schema in a revision
> increment.
>
> If a change is not possible while maintaining that compatibility, then it
> would need to be a new major version, and therefore the tool that doesn't
> understand that version will not be able to process the file.
>
> Daniel
>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>