Remove the version enums from schemas

[afrittoli]

Changes

Including the spec version enums in schemas is problematic, because every time the spec is updated it implies that all the event schemas must be updated as well which in turn requires the event type versions to be updated too, which is confusing since not all events are updated when a new spec version is made.

To solve that issue, we remove the enum from the version property, a let it be a non-empty string. The SDKs can use the event type and version to download the schema and validate events.

When a new spec release is made, the $id in the schema of all events still have to be updated, but that should not cause the version on the event type to be updated.

Fixes #87

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

[e-backmark-ericsson]

What about the "0.1.1" reference in the $id field above? That also needs to be changed if we shouldn't need to update all schema files for each event version, or?

[afrittoli]

The "$id" field has no impact on the schema itself, it's only an URL from where the schema can be fetched.
My feeling is that when a new spec version is made, new ids are created, but the ids for a specific message will return the exact same schema (except for the id) if the new spec didn't introduce a change for that event.

For instance, the following two IDs:

• "$id": "https://cdevents.dev/0.1.1/schema/artifact-packaged-event",
• "$id": "https://cdevents.dev/0.2.0/schema/artifact-packaged-event",

May return a schema for the same event - i.e. "dev.cdevents.artifact.packaged.0.1.0".
After this PR I will add a PR which adds the event type as a default value in the schema, which will make this more clear from just looking at the schema.

[e-backmark-ericsson]

I'm afraid I don't follow completely. These $id's still confuse me...
You're saying that we don't need to update each event schema when we define a new spec version? So, if e.g. artifact.packaged is updated to event version 0.1.1 in spec version 0.1.2, and not updated for spec version 0.1.3, the schema for artfact.packaged will not be changed and still have this $id: https://cdevents.dev/0.1.2/schema/artifact-packaged-event?
I assume we will still deploy the schema for artifact.packaged on 0.1.3, but the result when fetching if for 0.1.2 and 0.1.3 will be identical, including the $id field in that schema retrieved (pointing at spec version 0.1.2 for both)?

[erkist]

I think that is exactly what Andrea meant. If an event definition has not changed, we will just "deploy" the same definition to the new spec version location (so 0.1.2 and 0.1.3 will point to identical definitions but on different URLs.)