feat(release-automation): continue rc/alpha numbering across a repo split via seeded_from - #442
Merged
hdamker merged 3 commits intoSep 4, 2026
Conversation
…lculation Repository splits move APIs into a new repo whose own release history is empty, so pre-release numbering would otherwise restart at rc.1/alpha.1 and collide with versions already published in the predecessor repo (e.g. QoSProfiles r1.1 vs QualityOnDemand's qos-profiles). version_calculator.py now reads release-plan.yaml's seeded_from.apis[].last_rc_api_version / last_alpha_api_version and folds the matching value in as one virtual history entry, matching the schema shipped in ReleaseManagement PR #660.
…ANGELOG baseline resolves A repo-split API's first release(s) have no self-history, so _get_compare_base always returns N/A regardless of seeding -- correct per design (cross-repo CHANGELOG diffing stays manual), but N/A gives the codeowner no hint that a real baseline exists in the predecessor repo. The Release Review PR now adds a one-line note pointing at seeded_from.repository/release_tag whenever an API has no comparison_baseline and was listed under seeded_from.apis, regardless of release status (rc/alpha/public alike).
… alert Plain blockquote text was easy to miss in the Release Review PR body. GitHub's > [!NOTE] alert syntax renders it with a colored icon and border, matching how similar callouts already look elsewhere in CAMARA repos.
hdamker
added
enhancement
Contributor
Author
|
Needed for QosProfiles, including into tooling release v0.10.0 |
This was referenced Sep 4, 2026
Closed
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
1 participant
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?
enhancement/feature
What this PR does / why we need it:
Adds an optional
seeded_fromsection torelease-plan.yaml(schema already added in ReleaseManagement#660) that declares a one-time, hand-typed fact when an API is split into a new repository: the last rc/alpha version already published for that API in its predecessor repository.VersionCalculator.calculate_versions_for_planfolds the declaredlast_rc_api_version/last_alpha_api_versionin as one virtual entry alongside this repository's own release history when computing the next extension number, so a brand-new split-off repository continues numbering (e.g.1.2.0-rc.3to1.2.0-rc.4) instead of restarting atrc.1and colliding with an unrelated, earlierrc.1. Public releases are unaffected since they never read history or the seed. Separately, when an API's CHANGELOG comparison baseline can't be resolved from this repository's own history and that API is listed underseeded_from, the Release Review PR now adds a[!NOTE]alert pointing at the predecessor repository/tag, since cross-repo CHANGELOG history stays a manual step regardless of this change.Which issue(s) this PR fixes:
Fixes #441
Special notes for reviewers:
Two files are intentionally untouched:
shared-actions/create-snapshot/action.ymlalready passes the fullrelease-plan.yamldict through tocalculate_versions_for_plan, andrelease-plan.yaml'starget_api_versionis base-version-only (the extension is always auto-calculated, never hand-typed), so there is no PR-time value to validate againstseeded_frombeyond what the schema already enforces inresolve-release-history.py/release_history.py.validation/schemas/release-plan-schema.yamlis a manual copy of the ReleaseManagement#660 schema (this repo doesn't fetch it live) - a future drift between the two needs to be caught by hand. End-to-end verified against a real (non-fork) mirror repository seeded fromQualityOnDemand's actualqos-profileshistory, confirming1.2.0-rc.3to1.2.0-rc.4through the realcreate-snapshotGitHub Action, not just unit tests.Changelog input
Additional documentation
This section can be blank.