Release 1.3 (M4 Fall25)

[FabrizioMoggio]

What type of PR is this?

• documentation

What this PR does / why we need it:

This is the M4 PR for the public version of the EFN API, for the Fall25 Meta Release. The PR changes the API version from WIP to 0.1.0 ad provides the updated README.md and CHANGELOG.md files.

Which issue(s) this PR fixes:

#100

[hdamker]

@FabrizioMoggio I've done first round of review and provide here the results. Please do all needed changes which are not directly related to the release within separate PRs and update the release PR branch afterwards from main.

API Name - critical:

• I understand that you changed the API name during the review of rc.1 by @tanjadegroot from energy-footprint-notification to energy-footprint
• But the change has been done only partly:
  • file names of the API and test definitions should use the API name, they are still energy-footprint-notification
  • the CHANGELOG.md still lists energy-footprint-notification
  • the CloudEventType uses still energy-footprint-notification as api-name
  • the test definition is still using the previous server URL (and is therefore inconsistent with the YAML)
• My recommendation would be to revert back to energy-footprint-notification as API name. Why:
  • Asynchronous, callback-based API; “notification” clarifies the delivery model
  • Avoids ambiguity of “energy-footprint” (which suggests synchronous query)
  • Already consistent with repository name, file names, CloudEvent types and test definitions -> less alignments needed across all files
• Alignments to make:
  • Servers base path: {apiRoot}/energy-footprint-notification/v0.1
  • OAuth scopes: energy-footprint-notification:calculate-energy-consumption, energy-footprint-notification:calculate-carbon-footprint
  • Title

Callbacks/Events

• They "MUST use the media type application/cloudevents+json" (currently "application/json"), see https://github.com/camaraproject/Commonalities/blob/main/documentation/CAMARA-API-Event-Subscription-and-Notification-Guide.md#31-event-notification-definition
• Otherwise the event POST would also not fit to the defined callback sink

Info.description

• In info.description, remove outdated endpoint bullets (e.g., /overall-energy-consumption) that do not match actual paths (/calculate-energy-consumption, /calculate-carbon-footprint).

[hdamker]

Note: the request for changes is mainly related to the issues in #98 (comment).
Please update the PR from main when the needed alignments are done and mark the PR again as ready for review.

[FabrizioMoggio]

If you plan to run the PR with non-release changes first, you might want to consider to set the PR here to draft until done.

I have already done the WIP PR (#103), now this PR should be ok and ready to be reviewed/approved

[hdamker]

I have already done the WIP PR (#103), now this PR should be ok and ready to be reviewed/approved

@FabrizioMoggio yes, much nicer now. Even our release validation workflow is happy. Will continue with the review.

[hdamker]

@FabrizioMoggio looks already quite good, some smaller comments on the CHANGELOG.md

[hdamker]

Beyond the above comments there is a fix of the ErrorInfo schema in CAMARA_common.yaml which will come in a patch release of Commonalities. You can apply it already now as the fix is compliant to r3.3 of the API Design Guide, but it is neither critical nor mandatory for you now:

• ErrorInfo Schema properties alignment Commonalities#517 (issue #515)

If you apply it now then please again in a separate PR against main.

[FabrizioMoggio]

Beyond the above comments there is a fix of the ErrorInfo schema in CAMARA_common.yaml which will come in a patch release of Commonalities. You can apply it already now as the fix is compliant to r3.3 of the API Design Guide, but it is neither critical nor mandatory for you now:

• ErrorInfo Schema properties alignment Commonalities#517 (issue #515)

If you apply it now then please again in a separate PR against main.

If not mandatory, at this point, I prefer not to engage the supporting partners on another round of wip-approval-merge-align- etc. This would be easy for this API but for TI API and CFS API I need more coordination with the other members. For this reason I'm planning to keep this issue open for all my APIs and fix it for the next meta release. The time is a great constraint at this point.

[hdamker]

If not mandatory, at this point, I prefer not to engage the supporting partners on another round of wip-approval-merge-align- etc. This would be easy for this API but for TI API and CFS API I need more coordination with the other members. For this reason I'm planning to keep this issue open for all my APIs and fix it for the next meta release. The time is a great constraint at this point.

@FabrizioMoggio That's fine and your decision. But just seen that in TrafficInfluence you need anyway to clean-up your legacy ErrResponse schema(s).

[FabrizioMoggio]

If not mandatory, at this point, I prefer not to engage the supporting partners on another round of wip-approval-merge-align- etc. This would be easy for this API but for TI API and CFS API I need more coordination with the other members. For this reason I'm planning to keep this issue open for all my APIs and fix it for the next meta release. The time is a great constraint at this point.

@FabrizioMoggio That's fine and your decision. But just seen that in TrafficInfluence you need anyway to clean-up your legacy ErrResponse schema(s).

If I have other issues to fix I will also include it.

[FabrizioMoggio]

ErroInfo fixed

[hdamker]

ErroInfo fixed

Unfortunately not ... you changed only the order in "required", but not the actual schema.

[FabrizioMoggio]

Everything has been addressed

[hdamker]

Everything has been addressed

Great! I will approve now for release management. You might want to consider to remove the placeholder README.md files in the directories. Happy to approve again, if you dismiss my approval with that.

[hdamker]

Approved on behalf of Release Management 👏

Next steps for the team:

• PR merged (by API repository codeowner)
• Release created within GitHub (by API repository codeowner)
• Release Tracker updated (with creation date of the release and the release tag link)

[FabrizioMoggio]

Everything has been addressed

Great! I will approve now for release management. You might want to consider to remove the placeholder README.md files in the directories. Happy to approve again, if you dismiss my approval with that.

Dear Herbert, I'm sorry I didn't notice this request of yours before creating the release.

[hdamker]

Dear Herbert, I'm sorry I didn't notice this request of yours before creating the release.

No worries, the files are doing no harm. Let's delete them together with the reset to wip.

[FabrizioMoggio]

Dear Herbert, I'm sorry I didn't notice this request of yours before creating the release.

No worries, the files are doing no harm. Let's delete them together with the reset to wip.

I'm sorry I'm not sure how to proceed because I'm not sure to have got you right :-). The release has been merged and the release tag created. I will delete the file when a new wip will be created. For the next release I mean. Is my understanding right?