Start release v0.2.0 and add tooling

[afrittoli]

Changes

Start release v0.2.0 by setting the release on main to v0.2.0-draft.

Add a new tool in tools/spec-release.sh which can be used to start, end and patch a release. The tool edits the IDs in the schema files and all required examples in the docs.

Signed-off-by: Andrea Frittoli andrea.frittoli@gmail.com

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has the primer doc been updated if a design decision is involved
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy
• Meets the CDEvents contributor standards

[afrittoli]

Current dependencies on/for this PR:

• main
  • PR Start release v0.2.0 and add tooling #92 👈

This comment was auto-generated by Graphite.

[e-backmark-ericsson]

I still don't understand why the $id field is needed in the schemas. It feels like if a source code file would know where it will be deployed. Is the $id field really necessary? What happens if we for some reason need to change our website url later, would all old schema files be invalid then? It would be simpler if we didn't need to update all json files for each patch release and for the spec release itself.

[afrittoli]

I still don't understand why the $id field is needed in the schemas.

"$id" is not strictly needed as long as long as the whole schema is together.

I started using schema in the first iteration because I was using a base schema (same for all events) and sub-schemas, but that was replaced, based on feedback, with a single schema for each event.

Later I used golang to generate schemas, and the library I used for that by default generates an ID which points with the file location on github, so I gathered it was considered a good practice to have an ID.

It feels like if a source code file would know where it will be deployed. Is the $id field really necessary?

It's for other schemas to be able to reference it.

What happens if we for some reason need to change our website url later, would all old schema files be invalid then? It would be simpler if we didn't need to update all json files for each patch release and for the spec release itself.

Things can change for sure, but I think that using a domain we own like cdevents.dev is as good as it gets in that sense.

[afrittoli]

Personally, I like having the link in the schema file to the release version it belongs to, but if you'd definitely don't want IDs we could remove them.

IDs can also be relative I think, in which case the full ID (for an external reference) is computed as the location where the schema is hosted plus the relative ID. I like in absolute IDs that we can pick the base URL to be cdevents.dev instead of github.com

[afrittoli]

Personally, I like having the link in the schema file to the release version it belongs to, but if you'd definitely don't want IDs we could remove them.

IDs can also be relative I think, in which case the full ID (for an external reference) is computed as the location where the schema is hosted plus the relative ID. I like in absolute IDs that we can pick the base URL to be cdevents.dev instead of github.com

I wonder if we could continue this discussion as a follow-up since this PR (and the next one) is a blocker right now for starting any work on v0.2?

[e-backmark-ericsson]

Ok. Let's leave the $id there for now, and potentially remove it later if we see it hinders us more than it benefits us.