Release NAM 0.1.0-alpha.1

[clundie-CL]

What type of PR is this?

• subproject management

What this PR does / why we need it:

Prepares the first alpha pre-release (r1.1) of the Network Access Management API as version 0.1.0-alpha.1. This release reflects a significant refactor from the original "Isolated Networks" design to a "Trust Domains" model, addressing the architectural and compliance feedback received during the Fall25 meta-release review (PR #73).

This PR contains only release artifact changes:

• Updated info.version from wip to 0.1.0-alpha.1 and server URL from vwip to v0.1alpha1
• Completed network-access-management-API-Readiness-Checklist.md
• Updated CHANGELOG.md with feature-level release notes

Which issue(s) this PR fixes:

Fixes #108

Does this PR introduce a breaking change?

• Yes
• No

Special notes for reviewers:

Experimental capabilities spec: The repository contains an experimental Device Capabilities spec (code/API_definitions/Templates/network-access-management-template.yaml) that retains wip status and is not part of this release. This file was part of an experiment with multi-file bundling strategies that informed [Commonalities #577](camaraproject/Commonalities#577) (CAMARA_common.yaml consumption and bundling discussion). We welcome guidance on how to handle experimental/WIP specs within the repository structure — whether they should be removed prior to release, relocated, or addressed in a follow-up.

Not targeting meta-release: This alpha pre-release is intended for early community feedback and is not targeting inclusion in the Spring '26 meta-release.

Commonalities alignment: This release targets alignment with Commonalities r3.4 and ICM r3.3.

Changelog input

First alpha pre-release of the Network Access Management API (v0.1.0-alpha.1), introducing Trust Domain lifecycle management, Reboot Request management, and supporting Service/Device resource endpoints.

Additional documentation

- Release tracker: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/548798466/Network+Access+Management+v0.1.0
- Fall25 review feedback: PR #73, Issue #77
- Commonalities bundling discussion: https://github.com/camaraproject/Commonalities/issues/577

[clundie-CL]

@camaraproject/release-management_reviewers @camaraproject/release-management-training_maintainers

Just a friendly reminder that we'd love any feedback on this alpha release. I know it's been busy with the new release process. We will be refactoring the repo structure according to the result of camaraproject/Commonalities#577 and preparing for a sync release using the new release automation. As such, maybe this release is going to be less about long-term usage, but at least capture relevant feedback that would be pertinent to the sync release candidate.

For reference, #117 is the PR opened to move towards camaraproject/Commonalities#577 compliance and prepare for piloting this functionality.

[tanjadegroot]

Team, apologies for the delay.

I recommend to adopt already the automated release process for your alpha release (this requires keeping any versioning on main as "wip" / "vwip").

Here are the proposed next steps:

1. @hdamker to please create the "reset-to-wip" PR that will take care of this.
2. Team to merge the PR "Reset API and test code version information to wip"
3. Release Automation Onboarding — @hdamker to create a PR to onboard the repository to the new CAMARA Release Workflow. This will include removing the existing CHANGELOG.md and the API Readiness Checklists, as these will be managed per release cycle going forward.
4. Team to merge this PR
5. API release planning via release-plan.yaml — Team to create a dedicated PR to update the release plan to the appropriate values as follows:

• target_release_type: pre-release-alpha
• replace the "placeholder-entry" by the actual API name
• target_api_status : alpha

6. Team to merge this PR. This results in the creation of the Release Issue which is the base to manage your API release with the automated process.

I will review this PR, but will ignore versioning aspects.
You can either remove all version updates from this PR before merging, or you can merge as is and apply step 2 above to resent to wip/vwip.

[hdamker]

@tanjadegroot @clundie-CL

I consider this PR here as outdated ... since then the repository has been restructured significantly (see #115). Regarding using the release automation I agree, but for that it need to support bundling, which is currently not yet the case. I'm working on it ... hopefully we have it before Easter ready for an "alpha" test.

Regarding the points above:
1+2: the main branch is clean ... only non-wip version is in common/CAMARA_common.yaml. There the 0.7.1 is wrong, as the next release will be 0.7.0-rc.2 (there was no public release of 0.7.0 yet).
3: will do when ready for bundling

[tanjadegroot]

@tanjadegroot

then it would probably be better to close this PR as it only does the version settings.

Agree ... that I meant with outdated.

I guess your comment raises the question if the release process should also update version in the new common directory and do this for all common files (CAMARA_common.yaml and dedicated common files)

CAMARA_common.yaml will come with the x-camara-commonalities version, which will be also persisted within the release-metadata.yaml in the repo release. No clue about dedicated common files if they need a version number - as the files will not be part of the release eventually, but only used as modules during the release build (bundling).

Could the folder restructuring already be done by hand or would you recommend to wait and have that done by an automation PR ?

My understanding that #117 went into this direction ... but haven't reviewed it, so could be that it does not fit the final structure. And yet, the structure has currently be set up by hand, automation might be done much later.