chore: declare split APIs (network-access-devices, network-access-domains) in release-plan as draft (#152)#154
Open
clundie-CL wants to merge 3 commits into
Open
Conversation
Per release-management guidance for the API split (the hen-egg between release-plan api_names and the spec files): declare the two target APIs — network-access-devices and network-access-domains — at target_api_status: draft. Draft allows the spec files to land separately in the restructure PR (camaraproject#153) without a P-002 "declared API has no file" error; status is bumped to rc once the files are in place. This is a dedicated release-plan-only change so it satisfies P-022 (release-plan edits must not be mixed with other files). Co-Authored-By: claude-flow <ruv@ruv.net>
clundie-CL
requested review from
benhepworth,
caubut-charter and
mayur007
as code owners
P-009 (_check_release_type_consistency) rejects draft APIs while
target_release_type is pre-release-rc ("APIs are not rc/public"). The split
declares the two APIs as draft (so their files can land in camaraproject#153 without a
P-002 error), so the plan must be parked at target_release_type: none for
this phase. The rc-bump PR restores target_release_type: pre-release-rc when
it sets both APIs to rc.
Co-Authored-By: claude-flow <ruv@ruv.net>
P-009 flags a "naming mismatch" (blocking in the released tooling) when a declared draft API has no file AND an unmatched file is present — here the still-present network-access-management.yaml. Declaring network-access-management itself as draft removes the orphan, so the heuristic stays quiet. The restructure PR (camaraproject#153) deletes network-access-management.yaml (leaving a fileless draft with no orphans — still clean), and the rc-bump PR drops this entry and sets the two real APIs to rc. Co-Authored-By: claude-flow <ruv@ruv.net>
Contributor
@clundie-CL using 0.3.0 is definitely right if the functionality of the new APIs was already (partially) contained in the 0.2.0 NAM API version. If it is completely new functionality (never released before as part of NAM) you can consider also to use 0.1.0 to indicate that it is the first initial version of the new API. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
What this PR does / why we need it:
First step of the sequenced API split (see #153), per @hdamker's "draft status" guidance for the release-plan hen-egg. It declares the split API names in
release-plan.yamlso the restructure PR can add the matching spec files without tripping validation.Two adjustments are needed to keep this PR's validation clean (0 errors):
target_api_status: draft— draft allows the spec YAML to not exist yet (noP-002error). This includes keepingnetwork-access-managementas a transitional draft entry: with itsnetwork-access-management.yamlstill present, dropping it from the plan would make the file an orphan and tripP-009's "naming mismatch" (which the released tooling treats as blocking). Declaring it keeps the plan and the on-disk file consistent.target_release_type: none(parked) —P-009rejectsdraftAPIs while the repo targetspre-release-rc. Parking the plan is the supported state while the restructure is in flight.Sequence:
draft, park the release type.network-access-devices.yaml+network-access-domains.yamland deletesnetwork-access-management.yaml, with norelease-plan.yamlchange (so it isn't blocked byP-022).network-access-managemententry, setsnetwork-access-devices+network-access-domainstorc, and restorestarget_release_type: pre-release-rcfor the r3.1 cut.Relates to #152; unblocks #153.
Does this PR introduce a breaking change?
(Release-plan declaration only — no API surface change here. The split itself, in #153, is the breaking change.)
Special notes for reviewers:
S-309arraymaxItems,P-006test files,P-032legacy readiness checklist) — addressed in feat: split API into Network Access Devices + Trust Domains (#152) #153 / tracked separately.target_api_versioncarried over as0.3.0to stay aligned with the repo's r3.1 target — flagging for release-management confirmation in case fresh0.1.0numbering is preferred for the new api_names.Changelog input