[bulk] Sync Release Information section (2025-12-12-001)

[hdamker-bot]

Release Information Sync

This PR updates the Release Information section in README.md to reflect the latest public release information from the CAMARA project administration data.

What Changed

The Release Information section has been automatically updated to reflect the latest public release (r1.2) with current API versions and links to documentation viewers
in a harmonized way across all API Repositories in Fall25.

Instructions for Code Owners

IMPORTANT: This PR modifies content within automated delimiters in your README.md file:

<!-- CAMARA:RELEASE-INFO:START -->
...content managed automatically...
<!-- CAMARA:RELEASE-INFO:END -->

Content Preservation

If you have custom content in the Release Information section that should be preserved:

1. Before merging this PR: Move your custom content OUTSIDE the delimiter markers
2. Place it either after <!-- CAMARA:RELEASE-INFO:END --> within the "## Release Information" section or in an additional section with the heading "## Additional Information"
3. Content inside the delimiters will be replaced on every campaign run

Review Checklist

Review Focus: Verify delimiter placement and section structure only.

Content Validation Not Required: Release versions, dates, API names, and documentation links are automatically synchronized from releases-master.yaml and maintained by Release Management.

• Verify delimiters are correctly placed (wrapping entire "## Release Information" section)
• Confirm section heading remains "## Release Information"
• Move any custom content outside delimiters (if needed)
• Check that the automated content does not conflict with other README sections

Automation

This PR was created by the CAMARA project-administration release information campaign.

For questions or issues, please contact the CAMARA project administration team.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.01s
✅ API	spectral	3		0	4.08s
✅ GHERKIN	gherkin-lint	3		0	1.11s
✅ REPOSITORY	git_diff	yes		no	0.0s
✅ REPOSITORY	secretlint	yes		no	0.6s
✅ YAML	yamllint	3		0	0.67s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[tlohmar]

I would suggest to keep this line, as it acts more as a general introduction to the APIs. Maybe we can move this into the first section, i.e. before Scope. @hdamker Do you have a opinion or suggestion?

[hdamker]

@tlohmar Good point - the General Description reference is valuable for readers new to DedicatedNetworks given the complexity of the concepts (network slicing, NPNs, APNs, etc.).

Since this is foundational documentation rather than release-specific information, it should live outside the auto-managed Release Information section. Here are two options:

Option A: Single sentence before Scope (minimal change)

Add a brief reference line after the wiki link, before the Scope section:

* API Repository [wiki page](https://lf-camaraproject.atlassian.net/wiki/x/OICGAQ)

For background on Dedicated Networks concepts and workflows, see the [General Description](documentation/API_documentation/DedicatedNetworks_GeneralDescription.md).

## Scope

Option B: Dedicated section (more prominent)

Create a brief ## Background section for better visibility:

* API Repository [wiki page](https://lf-camaraproject.atlassian.net/wiki/x/OICGAQ)

## Background

For an introduction to Dedicated Networks concepts, key roles, and high-level workflows, see the [General Description](documentation/API_documentation/DedicatedNetworks_GeneralDescription.md).

## Scope

Recommendation: Option A is sufficient - it's concise and places the reference early without adding structural overhead. Option B makes sense if you want to add more context in the future.

Either way, using a relative path (documentation/API_documentation/...) rather than an absolute GitHub URL with branch reference is more maintainable (and will work also if the reader is looking on a specific release).

[tlohmar]

Yes, Option A is good. And yes, should be ok to have release specific information inside the doc.

[hdamker]

Done in 97b4194

[tlohmar]

Looks generally good.

One question on the relative URL. The README.md document seem to be available via two urls:

1. The content of the README.md document will be rendered at the bottom of the repo landing page, i.e. https://github.com/camaraproject/DedicatedNetworks/
2. The README.md document sits in the main branch, i.e. one can open it via https://github.com/camaraproject/DedicatedNetworks/blob/main/README.md

Does this relative url (document/API_.... or ./document/API_...) work in both cases?

[hdamker]

Does this relative url (document/API_.... or ./document/API_...) work in both cases?

Yes they do. You can have a look and test on https://github.com/camaraproject/Commonalities/blob/main/README.md if you like (there is a wild mix of file relative and root relative links ... but both work in this case as README.md is at the root of the repository). The links are relative to the file in the repository or the root of the repository, independent of how they are shown in GitHub. Cf. https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#relative-links

Use full qualified links only if you want to ensure that the reader goes to a specific released version or always to the most current in main branch.