search

camaraproject / NetworkAccessManagement

Repository to describe, develop, document and test the Home Devices - Network Access Management API
Apache License 2.0
2 stars 3 forks source link

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

Closed caubut-charter closed 2 months ago

caubut-charter commented 3 months ago

Create release v0.1.0.

What type of PR is this?

Add one of the following kinds:

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[bot] commented 3 months ago

🦙 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 OX Security_

hdamker commented 3 months ago

@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 #19 and #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.:

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

RandyLevensalor commented 3 months ago
  1. 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).
  2. 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:

hdamker commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

Closing to redo as non-meta.