Release Review: NumberVerification r4.1 (rc Sync26)

[camara-release-automation]

Release Review: r4.1 rc

This PR finalizes the reviewable release content for the active snapshot.

Edit and review this PR before merging it into the release snapshot. After Codeowner and Release Management approval, merging this PR creates the draft release.

Release contents

API	Version	Status	Comparison target
number-verification	2.1.1-rc.2	rc	2.1.0

Dependencies: Commonalities r4.3, ICM r4.2

Codeowner Actions

Tick each box once done. Ticking the last box — "The release is ready for Release Management review" — starts the Release Management review.

• Update the CHANGELOG

  What to do:

  • Copy all API-consumer-relevant changes from the provided list into the appropriate Breaking changes / Added / Changed / Fixed / Removed sections for each API. List breaking changes both in Breaking changes and in their normal change category.
  • Do not copy administrative, tooling-only, or internal maintenance changes unless they affect API consumers.
  • For each API, fill the CHANGELOG against the stated comparison target, following the release-type rules at the top of the CHANGELOG.

• Document deferred validation warnings (and hints)

  What to do:

  • Check the CAMARA Validation comment on this PR for warnings and hints.
  • For each warning you do not fix, document it in an issue: include a copy of the validation summary line(s) and the reason the fix is deferred.
  • Document in the same way any validation hint that is applicable to the API and needs to be fixed later.
  • You may group several findings into one issue or split them across issues — either is fine.
  • List the documenting issue(s) in a comment on this PR.
  • Note: documenting deferred warnings is optional but recommended for alpha pre-releases, and mandatory for rc pre-releases and public releases.

• The release is ready for Release Management review

  Check that:

  • All mandatory release assets for the declared status(es) are present (see the table below "Required release assets per API status" by expanding the arrow);
  • API documentation and test cases are adequate for the target status.

  Tick this box to confirm readiness and to start the Release Management review.

Release Management Actions

The following actions and checks are done by a Release Management reviewer before approving the PR:

• Assign the Release Management reviewer(s) as assignee(s) of this PR
• CHANGELOG follows the release documentation rules
• Breaking changes are documented and version updates follow SemVer rules
• Mandatory release assets are present for each API according to its status
• All remaining validation warnings are documented in issues and the reasons for deferral are defensible

Required release assets per API status

Nr	Asset	alpha	rc	initial public	stable public
1	Release Plan	M	M	M	M
2	API Definition(s)	M	M	M	M
3	Commonalities compliance	O	M	M	M
4	API Documentation	M	M	M	M
5	User Stories	O	O	O	M
6	Test Cases (basic)	O	M	M	M
7	Test Cases (enhanced)	O	O	O	M
8	API Description	O	O	M	M

M = Mandatory, O = Optional — Full documentation

Valid next actions for codeowners

• Merge this PR when all Codeowner Actions and Release Management Actions are complete and the required approvals are present — creates the draft release
• Use /discard-snapshot <reason> in the Release Issue to discard this snapshot, return to planned, and update content on main

---

Snapshot: r4.1-bb0c748

[camara-validation]

CAMARA Validation — PASS (with warnings)

0 errors, 1 warnings, 0 hints | Profile: standard

View full results

Warnings MUST be documented in one or more issues before this release — see the Codeowner Actions in the PR description.

[tanjadegroot]

Hi team, please complete the code owner actions, thanks !

[albertoramosmonagas]

Hi @AxelNennker & @bigludo7, I don't have permission to mark the boxes as “done,” but I'd say that, as far as TEF is concerned, there's nothing else to do here so as not to block the release management review (@tanjadegroot). WDYT?

[hdamker]

I've reviewed the PR and content changes of this release. The two content findings are collected in #245:

• the reference of Generic400 has accidentally defined an additional error response code (OUT_OF_RANGE) which wasn't present in v2.1.0. As this addition would be breaking change and would need to be documented as such, I recommend to fix #247 on main before creating r4.1
• #246 is more cosmetic, but as this is a validation warning it must be documented as deferred or fixed. It is also easy to fix, a small inconsistency in applying the ref/bundling.

Three additional points regarding the release process - for the next snapshot after the fix:

• please do the codeowner actions timely and tick them off to avoid further delays in the release process ... please check also the validation results here on the Release Review PR ... the warning was not documented in an issue
• document the relevant changes from #235, especially the newly documented request-body strictness, and the PR #235 itself for information in the CHANGELOG
• The Design Guide RECOMMENDs a minor bump when an existing API adopts the request-body-strictness template ("Stable APIs (version ≥ v1.0): minor bump"). This release adopts it and ships as patch 2.1.1, which is worth a deliberate decision either way. It might be defensible, since NumberVerificationRequestBody already had maxProperties: 1 and therefore the behavior is unchanged for this API

[hdamker]

FYI: This snapshot was created before camaraproject/tooling#431 got active with tooling release v0.10.0. #431 moved the automated README Release Information update from the release-review branch onto the snapshot branch. The merge commit above brings this branch in line with that: the README update now lives on the snapshot branch, so this branch differs from it by the CHANGELOG only. No content change.

[bigludo7]

@hdamker - I'm a bit lost - May I discard this snapshot and then propose to merge #248 in order to move to commonalities r4.4?
Once done do I have to do something special to have the code/common synchronized from commonalities?
cc: @rartych

Thanks for your help

[hdamker]

@hdamker - I'm a bit lost - May I discard this snapshot and then propose to merge #248 in order to move to commonalities r4.4?
Once done do I have to do something special to have the code/common synchronized from commonalities?

@bigludo7 to get any fix on main into the release you have anyway to discard the current snapshot and create a new one after the fixes. So the steps are:

• discard the snapshot (via Release r4.1 (RC) — Sync26 #236)
• merge Update commonalities_release to version r4.4 #248 (you can re-run the validation to get a green validation check, but not needed)
  -> that will trigger the creation of a new automated PR to sync Commonalities r4.4 into the repo
• approve and merge the automated sync PR
• do the needed fixes in a PR against main branch
• create new snapshot (again via Release r4.1 (RC) — Sync26 #236)