Good catch Rafal :-)

@tanjadegroot In line 145 replace:
type must follow the format: org.camaraproject.<api-name>.<api-version>.<event-name> with the api-version with letter v and the major version like org.camaraproject.device-roaming-subscriptions.v1.roaming-status

with:
type must follow the format: org.camaraproject.<api-name>.<event-version>.<event-name> - see chapter 2.3. Event versioning

@tanjadegroot In line 145 replace: type must follow the format: org.camaraproject.<api-name>.<api-version>.<event-name> with the api-version with letter v and the major version like org.camaraproject.device-roaming-subscriptions.v1.roaming-status

with: type must follow the format: org.camaraproject.<api-name>.<event-version>.<event-name> - see chapter 2.3. Event versioning

another goo d catch. I though that had already been changed. Should the note on an array value be kept ?

Should the note on an array value be kept ?

Yes - it will be changed with PR #477 - I hope without conflict.

Also align some information in https://github.com/camaraproject/Commonalities/blob/main/artifacts/camara-cloudevents/event-subscription-template.yaml#L8.

Replace:

Note on event name convention: the event type name MUST follow: org.camaraproject.<api-name>.<api-version>.<event-name>

By

Note on event name convention: the event type name MUST follow: org.camaraproject.<api-name>.<event-version>.<event-name>

cc @tanjadegroot, @rartych

Also align some information in https://github.com/camaraproject/Commonalities/blob/main/artifacts/camara-cloudevents/event-subscription-template.yaml#L8.

Replace:

Note on event name convention: the event type name MUST follow: org.camaraproject.<api-name>.<api-version>.<event-name>

By

Note on event name convention: the event type name MUST follow: org.camaraproject.<api-name>.<event-version>.<event-name>

cc @tanjadegroot, @rartych

Fixed - I checked for all occurrences of "api-version" and they are covered now (where applicable)

@rartych @hdamker I know we discussed this, but at second thought I think this is the last (good) opportunity to change the place of the version field to put it behind the event-name: api-name.event-name.event-version

Advantage: Putting the event-version after the event-name may help in reducing any confusion wrt to the API version.

I checked, and currently we have around 8 subscription APIs (6 in Spring25) and all are still initial APIs so it should not be a big deal if we change now.

We can leave the API updates to be done for M4.
I can do a quick update of the PR

@rartych @hdamker I know we discussed this, but at second thought I think this is the last (good) opportunity to change the place of the version field to put it behind the event-name: api-name.event-name.event-version

Advantage: Putting the event-version after the event-name may help in reducing any confusion wrt to the API version.

I checked, and currently we have around 8 subscription APIs (6 in Spring25) and all are still initial APIs so it should not be a big deal if we change now.

We can leave the API updates to be done for M4. I can do a quick update of the PR

As far as I have seen unique stable API impacted would be "quality-on-demand". Rest of impacted APIs are initial versions so far

@rartych @hdamker I know we discussed this, but at second thought I think this is the last (good) opportunity to change the place of the version field to put it behind the event-name: api-name.event-name.event-version

Advantage: Putting the event-version after the event-name may help in reducing any confusion wrt to the API version.

I checked, and currently we have around 8 subscription APIs (6 in Spring25) and all are still initial APIs so it should not be a big deal if we change now.

We can leave the API updates to be done for M4. I can do a quick update of the PR

• I'm also in principle in favor of doing the change, but won't do it here on the fly without a proper discussion as there are pros and cons for both approaches. I found a lot of evidence that putting event-version after the event-name (aka "action"), but propose to discuss that in a separate issue and pull request
• If we do the change we should use it as an exercise how to introduce such a change without forcing APIs to break backward compatibility just for the sake of this change. The way could be to define it as the target schema, but allow APIs to keep the current structure at least until their next major version (or even until the update the event structure).

As codeowner in QualityOnDemand I would like to keep the v1.0.0 API and v1 "event family" stable, and change to a new event versioning approach only later (or not at all as long there are no other changes to the event data structure). We don't have the alternative to offer both event types in parallel unfortunately.

@rartych @hdamker I know we discussed this, but at second thought I think this is the last (good) opportunity to change the place of the version field to put it behind the event-name: api-name.event-name.event-version
Advantage: Putting the event-version after the event-name may help in reducing any confusion wrt to the API version.
I checked, and currently we have around 8 subscription APIs (6 in Spring25) and all are still initial APIs so it should not be a big deal if we change now.
We can leave the API updates to be done for M4. I can do a quick update of the PR

• I'm also in principle in favor of doing the change, but won't do it here on the fly without a proper discussion as there are pros and cons for both approaches. I found a lot of evidence that putting event-version after the event-name (aka "action"), but propose to discuss that in a separate issue and pull request
• If we do the change we should use it as an exercise how to introduce such a change without forcing APIs to break backward compatibility just for the sake of this change. The way could be to define it as the target schema, but allow APIs to keep the current structure at least until their next major version (or even until the update the event structure).

As codeowner in QualityOnDemand I would like to keep the v1.0.0 API and v1 "event family" stable, and change to a new event versioning approach only later (or not at all as long there are no other changes to the event data structure). We don't have the alternative to offer both event types in parallel unfortunately.

OK, actually, I think one could introduce the change by adding a new event type (with the same version in a different place) and a copy of the same event structure in a backward compatible way in a next release, and and deprecating the old one 2 releases later (as per the standard defined procedure).

OK, fine to take time for more discussion on this.
And please don't sneak in the "F" word again :-) (ref. "family" in your text above. just "v1 events" can do).

/LGTM as is then.

OK, actually, I think one could introduce the change by adding a new event type (with the same version in a different place) and a copy of the same event structure in a backward compatible way in a next release, and and deprecating the old one 2 releases later (as per the standard defined procedure).

That's unfortunately does not work with implicit subscriptions like in quality-on-demand.

And please don't sneak in the "F" word again :-) (ref. "family" in your text above. just "v1 events" can do).

Sorry ... I guess we have called it an "event set" in the discussion.

Am I assuming correctly that this merge will be done by the commonalities team or should I do it ?
thanks !