On Wed, Dec 13, 2023 at 08:36:41 -0500, Bret Brown via SG15 wrote:
> 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.

With these files being useful for more than just the-current-build, yes,
concurrent metadata provisions may be warranted in order to not
(unnecessarily) break older tools. Naming with the major version in the
name would allow for older tools to use older metadata descriptions and
newer tools to get the new ones. However, if some new field is required,
then the older, insufficient metadata files can be dropped. This seems
reasonable to me (and is something we can talk about in the Ecosystem
IS!).

> 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.

I think filename-based lookup is ideal here. So `libname.modules.vN.json` or
whatever.

--Ben