New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add event_manifest.yml and a script to generate it #353
Conversation
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good!
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. |
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.) |
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. |
231bec8
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 <magnus.back@axis.com>