[bulk] Enable release automation and validation

[camara-release-automation]

Enable release automation and validation for DeviceIdentifier

TL;DR: This PR adds the release automation workflow and the CAMARA Validation workflow, and prepares the CHANGELOG structure for DeviceIdentifier.

Note: Once merged, the release automation becomes active.
A Release Issue will be created automatically (if not existing yet) when release-plan.yaml is updated on main.

What is this?

The release automation workflow enables slash commands on Release Issues to manage your release lifecycle. Post these as comments on the Release Issue:

• /create-snapshot — create a snapshot branch (updates versions, changelog entries, and release metadata automatically)
• /discard-snapshot <reason> — discard a snapshot and return to planned state
• /delete-draft — delete a draft release
• /publish-release --confirm rX.Y — publish the release

Changes

File	Description
.github/workflows/release-automation.yml	Release automation workflow (pinned to @v1-rc)
.github/workflows/camara-validation.yml	CAMARA Validation workflow (pinned to @v1-rc)
CHANGELOG.md	Added forward-reference note
CHANGELOG/README.md	Created index file (with historical reference)

What to do next

1. Review the file changes above
2. Merge this PR to activate the release automation

If release-plan.yaml was updated before this workflow was installed, you may need to trigger the workflow manually once to create the initial Release Issue:

• Go to Actions → Release Automation → Run workflow

Release lifecycle overview

1. Plan — update release-plan.yaml with target release tag, type, and API versions/statuses
2. Develop — continue work on main branch with version fields set to wip
3. Create Snapshot — post /create-snapshot on the Release Issue to generate a Release PR
4. Review & Merge — review Release PR (includes CHANGELOG entry), obtain approvals, merge it
5. Publish — post /publish-release --confirm rX.Y to finalize the release

If issues arise: use /discard-snapshot (during review) or /delete-draft (during draft phase) to return to planned state and make corrections on main.

More details: Release Lifecycle

Documentation

📖 Release Management Documentation
📖 Release Lifecycle
📖 The release-plan.yaml File

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	4		0	0.01s
✅ API	spectral	1		0	1.73s
✅ GHERKIN	gherkin-lint	3		0	1.07s
✅ REPOSITORY	git_diff	yes		no	0.02s
✅ REPOSITORY	secretlint	yes		no	0.64s
✅ YAML	yamllint	1		0	0.49s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[hdamker]

@eric-murray @Kevsy would be great if one of you would approve and merge this PR ... that will bring in a next the code/common directory with the Commonalities r4.2 files into the repository.

[Kevsy]

LGTM

[eric-murray]

@eric-murray @Kevsy would be great if one of you would approve and merge this PR ... that will bring in a next the code/common directory with the Commonalities r4.2 files into the repository.

Hi @hdamker

I even see a warning triangle about this!

There is an API meeting tomorrow, where we will approve merging this PR, and also discuss doing an initial alpha release before the RC.

[hdamker]

There is an API meeting tomorrow, where we will approve merging this PR, and also discuss doing an initial alpha release before the RC.

@eric-murray Sorry, I overlooked that when merging the PR.

As this is not a decision about whether to do an alpha release, but only about when to do it, I proceeded with the merge, based on the fact that release-plan.yaml is already set to Commonalities r4.2.

The decision on when to do an alpha release is completely up to the team. We would be glad to see repositories try such a release before Commonalities cuts the public release.

There is also the option to go only as far as the snapshot stage and inspect what the release branch would look like. Such a snapshot can always be discarded and recreated later.