Add event_manifest.yml and a script to generate it

[magnusbaeck]

Applicable Issues

Fixes #342

Description of the Change

This new file lists all available editions, what event types are available in each, and the latest available version of each event type in each edition. This is useful for automation and SDK generation.

Alternate Designs

None in particular, but one could of course always quibble over the schema of the generated file.

Benefits

It'll be easier to programmatically process the protocol and its editions.

Possible Drawbacks

It does introduce a wrinkle in the release process because of the chicken-and-egg problem with the availability of the tag (see change in release-process.md).

Contributors with old forks that don't contain all the tags will get CI failures until all edition-* tags have been pushed into their fork.

Sign-off

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

Signed-off-by: Magnus Bäck <[email protected]>

[m-linner-ericsson]

Good!

Any thought on the manifest file ordered by name and not by edition release date?

[e-backmark-ericsson]

Any thought on the manifest file ordered by name and not by edition release date?

I had a similar thought, but as long as the manifest does not contain release dates it makes more sense to sort it in alphabetical name order. If the release date is sometime included as well it could make more sense to have it sorted on that date.

[magnusbaeck]

I also considered adding a date or similar to make it possible to order the editions. Might be useful in some visualization cases. I could easily make the values in the _EDITIONS dict a tuple consisting of a tag and a date. (If we'd been consistent in using annotated tags we could've extracted the date from the tag objects, but I think it's only Arica that uses an annotated tag.)

[magnusbaeck]

Talked to Emil yesterday and I'll add a release date field to the YAML file, but the date can't be safely generated so it'll have to be included in the _EDITIONS dict as noted above.