Create release r1.1 with network-access-management v0.1.0-rc.1

[caubut-charter]

Create release v0.1.0.

What type of PR is this?

Add one of the following kinds:

• subproject management

What this PR does / why we need it:

Prepares for an initial alpha release.

Which issue(s) this PR fixes:

N/A

Special notes for reviewers:

Changelog input

N/A

Additional documentation

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.03s
✅ OPENAPI	spectral	1		0	3.04s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.66s
✅ YAML	yamllint	1		0	0.76s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[hdamker]

@caubut-charter @RandyLevensalor

In order to review it (on behalf of release-management) I would need to understand the purpose of this PR. I can't find any meeting minutes therefore I'm lacking here the context.

I see three options:

1. you want to do a release with the current content of the API specification and the content as currently here in the checklist - that would from my perspective an alpha release, as it is not yet in line with Commonalities 0.4.0(-rc.1)
2. you plan to resolve Commonalities pass for corrections #19 and ICM pass for corrections #20, update the checklist accordingly, and then create with this PR here the release r1.1 with network-access-management v0.1.0-rc.1 (the release candidate of v0.1.0).
3. you want to skip any pre-release, including the release candidate which is expected within the release cycle and create directly the public release v0.1.0

The option 2 would be in line with the intention of the M3 milestone in the release cycle for the meta-release Fall24 (cf https://wiki.camaraproject.org/display/CAM/Meta-release+Fall24). That would give you also the option of bug fixes and/or further alignments until M4 (end of August), where you would set the version then to v0.1.0 and create the public release.
With option 3 any necessary fixes until M4 would lead to another version number (either v0.1.1 or v0.2.0, depending if they are breaking or not).

Let's assume option 2.:

• The title of the PR should be "Create release r1.1 with network-access-management v0.1.0-rc.1"
• The changelog should reflect that it is a pre-release with the (first) release candidate of v0.1.0
• The PR should change within the YAML the version field from "wip" to "0.1.0-rc.1" and the path to .../network-access-management/v0.1rc1 (as this PR will be last to be merged before the actual creation of the release in GitHub)

Further minor comments I can provide if the purpose of the PR is clarified.

[RandyLevensalor]

2. you plan to resolve Commonalities pass for corrections #19 and ICM pass for corrections #20, update the checklist accordingly, and then create with this PR here the release r1.1 with network-access-management v0.1.0-rc.1 (the release candidate of v0.1.0).
3. you want to skip any pre-release, including the release candidate which is expected within the release cycle and create directly the public release v0.1.0

The option 2 would be in line with the intention of the M3 milestone in the release cycle for the meta-release Fall24 (cf https://wiki.camaraproject.org/display/CAM/Meta-release+Fall24). That would give you also the option of bug fixes and/or further alignments until M4 (end of August), where you would set the version then to v0.1.0 and create the public release. With option 3 any necessary fixes until M4 would lead to another version number (either v0.1.1 or v0.2.0, depending if they are breaking or not).

Let's assume option 2.:

• The title of the PR should be "Create release r1.1 with network-access-management v0.1.0-rc.1"
• The changelog should reflect that it is a pre-release with the (first) release candidate of v0.1.0
• The PR should change within the YAML the version field from "wip" to "0.1.0-rc.1" and the path to .../network-access-management/v0.1rc1 (as this PR will be last to be merged before the actual creation of the release in GitHub)

Further minor comments I can provide if the purpose of the PR is clarified.

@hdamker Your assumption regarding option 2 is corrected. Thanks for taking the time to review and provide guidance / clarification.

We are working to resolved Commonalities pass for corrections #19 and ICM pass for corrections #20. These are primarily updates from Commonalities and ICM that have been made since we last updated the API spec.

If I understand you feedback above, we should address issues #19 and #20, then make the following changes to this PR:

• Rebase if needed
• Update the PR title "Create release r1.1 with network-access-management v0.1.0-rc.1"
• Update the changelog to reflect that it is a pre-release with the (first) release candidate of v0.1.0
• Update version field from "wip" to "0.1.0-rc.1" and the path to .../network-access-management/v0.1rc1 (as this PR will be last to be merged before the actual creation of the release in GitHub)

[hdamker]

@caubut-charter @RandyLevensalor is there any update regarding the release preparation? Especially about progress on #19? I'm asking as the "cut-off" date for approved M3 release PRs is tomorrow (August 15th, cf https://wiki.camaraproject.org/display/CAM/2024-08-01+TSC+Minutes).

Another option is to take the time to properly do the alignment (maybe also the split as proposed in #26) and make the first initial release independent of the Fall24 release, aiming for the participation within Spring25 with one of the next versions.

Just let me know how you want to proceed.

Note: I took the freedom to edit the PR title and to tick off the point in the list above

[caubut-charter]

@hdamker Pushing to Spring25 for the meta release is the best option at this point.

I've had some priorities come up that likely won't slow down until after September with releases, conferences, and demos.

[caubut-charter]

Closing to redo as non-meta.