You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Automate repeatable public SynapseML releases for master / Spark 3.5 and
spark4.1. Spark 4.0 remains an explicit opt-in.
What this automates
Prepare version changes, release branches and versioned documentation.
Bind plans to reviewed commits, create immutable tags, and coordinate
publication with a durable release ledger.
Generate runtime-matched Databricks notebook archives from each approved
source commit. Strip saved outputs and verify every notebook through native
Databricks export and reimport.
Publish DBCs without overwrite to the existing public mmlspark/dbcs
container. Check anonymous downloads before PyPI and ESRP publication, then
include archive hashes in producer receipts and verified release notes.
Keep existing approved schema-2 plans unchanged. New schema-4 plans explicitly
approve notebook publication and require archive evidence for completion.
Support approved pre-merge trials, read-only dry runs and recovery after
partial or ambiguous submissions. Private integrations are not prerequisites.
Refuse release-note publication on failed GitHub lookups; only a confirmed
HTTP 404 authorizes creating a missing GitHub Release.
For 1.2.0, new plans require SynapseMLExamplesv1.2.0.dbc and SynapseMLExamplesv1.2.0-spark4.1.dbc. Opting into Spark 4.0 adds its matching
archive. Future versions derive their archive names from the approved Maven
versions. This addresses the recurring missing archives in #2346.
The operator guide
documents access prerequisites, approval, notebook preflight and recovery.
Plan approval, signing approval and PR merges remain human actions.
Default version bumps leave optional Spark 4.0 examples on their last release.
Validation and limits
The DBC integration was rebased onto master bccec7e73d. Range comparison
preserved all four earlier PR commits.
954 Linux release-tooling tests passed. One optional live SBT check was
skipped. The current-checkout notebook test passed separately with Windows
Git because WSL Git cannot open Windows-created worktree pointers.
All 12 installation-documentation tests passed, and changed Python follows
pinned Black 22.3.0. An earlier pipeline-only run passed 124 checks.
Real Databricks Workspace APIs round-tripped all 56 current notebooks,
preserving all 1,108 nonempty commands. This used a synthetic 0.0.0 archive
without blob publication or production tags.
Four available independent review rounds completed and all 13 findings were
addressed. Two unavailable Gemini rounds were skipped at maintainer request. Review evidence
records findings, fixes and limitations.
Notebook code was not executed on Databricks compute. Native archive
compatibility is not proof that every example runs without service setup.
The integration is pushed as f4b9473e5751d9ec9c157ac34565405952c17f61.
Azure build 238110760
has started for this head after /azp run. Hosted validation is still pending;
earlier-head checks do not validate this integration. Spark 4.1 PR compatibility
replay is advisory, but actual release candidates still require runtime-specific
validation.
Before publishing 1.2.0
This work has not published 1.2.0. Production publication remains blocked
until Python distribution works on both selected runtimes.
The primary PyPI wheel contains master's Python code, while spark4.1 has
additional compatibility fixes. Port-built wrapper tests do not validate the
primary wheel. Select and validate a cross-runtime wheel or matching
runtime-specific wheels, then update consumer instructions and inventory.
This DBC integration adds notebook publication to new approved plans; it does
not resolve the consumer-wheel packaging blocker.
Keep the PR unmerged until the requested pre-merge release trial is complete.
Hey Rana Singh (@ranadeepsingh) 👋!
Thank you so much for contributing to our repository 🙌.
Someone from SynapseML Team will be reviewing this pull request soon.
We use semantic commit messages to streamline the release process.
Before your pull request can be merged, you should make sure your first commit and PR title start with a semantic prefix.
This helps us to create release messages and credit you for your hard work!
Examples of commit messages with semantic prefixes:
fix: Fix LightGBM crashes with empty partitions
feat: Make HTTP on Spark back-offs configurable
docs: Update Spark Serving usage
build: Add codecov support
perf: improve LightGBM memory usage
refactor: make python code generation rely on classes
style: Remove nulls from CNTKModel
test: Add test coverage for CNTKModel
To test your commit locally, please follow our guild on building from source.
Check out the developer guide for additional guidance on testing your change.
## Summary
Refresh the release automation on current master, align it with the Fabric release guide and the live Publish-Official pipeline, and add proof-oriented coverage for release identifiers, artifact verification, GitHub workflows, and BBC-VHD edits.
## Prompting Intent
Refresh microsoft/SynapseML PR microsoft#2628 using the SynapseML PR readiness loop, follow the internal Fabric release guide, and derive automation from actual prior OSS, Internal, Publish-Official, and BBC-VHD releases rather than relying on stale examples.
## Linked Sources
- Fabric release guide: https://msdata.visualstudio.com/A365/_wiki/wikis/Osmos%20Team%20Wiki/130638/SynapseML-Fabric-Release-Guide-v2
- Release automation PR: microsoft#2628
- Derivative tag automation: microsoft#2540
- Live v1.1.3 release: https://github.com/microsoft/SynapseML/releases/tag/v1.1.3
- Publish-Official pipeline: https://msdata.visualstudio.com/A365/_build?definitionId=35879
- Historical BBC-VHD release PR: https://msdata.visualstudio.com/A365/_git/BBC-VHD/pullrequest/1805064
## Rationale
Keep ESRP, review, White-Glove, and train decisions human-gated while automating deterministic mechanics. Tag the exact reviewed merge, dispatch downstream GitHub automation explicitly because GITHUB_TOKEN pushes do not recurse, gate release notes on public artifacts, use the live pipeline parameter contract, fail loudly on incomplete network evidence, and roll back paired BBC-VHD writes rather than leaving partial release state.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds release-engineering automation to make SynapseML-to-Fabric releases more deterministic and reviewable, including a GitHub Actions “prepare → tag merged commit → publish notes” flow plus supporting Python tooling to derive/verify release identifiers and safely bump BBC-VHD pins.
Changes:
Introduces a release matrix generator (release_matrix.py) and an end-to-end verifier (verify_release.py) with accompanying tests.
Adds bump_bbcvhd.py (plus tests) to safely update BBC-VHD component pins while preserving line endings and rolling back on failure.
Adds/updates GitHub workflows for release prepare/tagging and manual, artifact-gated release notes; enables workflow_dispatch for PR validation so release PRs created via GITHUB_TOKEN can be validated.
Show a summary per file
File
Description
scripts/test_bump_version.py
Extends bump-version tests for denylisted repo-relative paths; normalizes path keys to POSIX.
scripts/bump-version.py
Improves Windows console encoding robustness; adds path-based denylist support; normalizes path handling via as_posix().
scripts/release/release_matrix.py
Adds a single-source-of-truth release matrix for tags and artifact versions + CLI rendering.
scripts/release/verify_release.py
Adds live verification of GitHub/ADO tags and Maven/PyPI/UPack/Azure Artifacts presence.
scripts/release/bump_bbcvhd.py
Adds deterministic, rollback-safe BBC-VHD component pin updater with CRLF/LF preservation.
scripts/release/README.md
Documents how to use the new release tooling and where it fits in the guide.
scripts/release/test_release_matrix.py
Adds regression/contract tests for the release matrix derivations and CLI validation.
scripts/release/test_verify_release.py
Adds unit tests for verifier networking/error handling and run plan behavior.
scripts/release/test_bump_bbcvhd.py
Adds tests for BBC-VHD bump idempotency, rollback, and newline preservation.
--skip internal does not currently skip the internal PyPI feed checks (the synapseml_internal package); it only skips internal git tag checks. This makes --skip internal behave inconsistently compared with --skip public.
def pip(self, package: str, version: str) -> str:
if "pip" in self.skip or "ado" in self.skip:
return SKIPPED
# Azure Artifacts normalises pypi names: synapseml_internal -> synapseml-internal
return (
OK
if version
in self._feed_versions("Synapse-Conda", "pypi", package.replace("_", "-"))
else MISSING
)
## Summary
Make --skip internal consistently skip SynapseML-Internal tags, UPacks, and wheels while retaining OSS artifact checks, and document every skip scope with regression coverage.
## Prompting Intent
Resolve all current-head automated review findings on microsoft/SynapseML PR microsoft#2628 and preserve an explicit, safe release-verification CLI contract.
## Linked Sources
- Release automation PR: microsoft#2628
- Internal artifact skip review: microsoft#2628 (comment)
- Skip help review: microsoft#2628 (comment)
## Rationale
A release operator who opts out of Internal verification must not still query or fail on Internal packages. Passing artifact scope explicitly keeps OSS checks active, avoids hiding public release gaps, and makes combined skip behavior predictable from both CLI help and maintainer documentation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The reason will be displayed to describe this comment to others. Learn more.
Review details
Suppressed comments (1)
Previously missed (1) — in code that hasn't changed since the last review.
scripts/release/verify_release.py:75
On Windows, subprocess.run(..., shell=True) expects a command string, but this code passes a list. That combination can fail (or behave differently) on win32, which would break the fallback ADO auth path even when az is installed. Build a platform-appropriate command (string for shell=True, list otherwise).
## Summary
Build the Azure CLI authentication command as a string only when Windows requires shell execution, while retaining an argument list and shell-free execution on other platforms. Add regression coverage for both command shapes.
## Prompting Intent
Resolve the current-head suppressed Copilot review finding on microsoft/SynapseML PR microsoft#2628 and prove the fallback authentication path used by release verification on Windows.
## Linked Sources
- Release automation PR: microsoft#2628
- Fabric release guide: https://msdata.visualstudio.com/A365/_wiki/wikis/Osmos%20Team%20Wiki/130638/SynapseML-Fabric-Release-Guide-v2
## Rationale
Windows resolves the Azure CLI through a command shim, so the verifier needs shell execution there; subprocess requires that shell command to be a string. Keeping list-based execution elsewhere preserves safe argument boundaries, while an actual token-less Windows replay proves the fallback can authenticate and inspect the live release.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addressed the current-head suppressed Windows auth finding in 6e80f27.
Windows now gives subprocess.run(..., shell=True) a command string; non-Windows retains an argument list with shell=False.
Parameterized regression coverage locks both command shapes.
A token-less Windows fallback replay authenticated through �z and found all 12 selected v1.1.3 master artifacts; the complete release-tooling suite is 279 passed.
The reason will be displayed to describe this comment to others. Learn more.
Review details
Suppressed comments (1)
Previously missed (1) — in code that hasn't changed since the last review.
scripts/release/verify_release.py:313
The Maven publication gate here verifies only synapseml-core_{scala} (via public_maven()), but the workflow-generated release notes advertise com.microsoft.azure:synapseml_2.12:${VERSION} (see .github/workflows/release-notes.yml:137) and the docs use the synapseml_2.12 coordinate (website/doctest.py:25). This can let verify_release.py report COMPLETE even if the primary install coordinate is missing (or vice versa). Consider aligning the verification to check the same Maven artifact(s) that users are instructed to consume (e.g., verify both synapseml_{scala} and synapseml-core_{scala}, or switch to the canonical one).
## Summary
Gate release completeness on both the user-facing synapseml_<scala> Maven coordinate and the release-guide synapseml-core_<scala> coordinate for every selected Spark target. Add a failing-install-coordinate regression and document the two-coordinate contract.
## Prompting Intent
Resolve the current-head suppressed Copilot review finding on microsoft/SynapseML PR microsoft#2628 by aligning artifact verification with generated release notes, installation docs, and actual published releases.
## Linked Sources
- Release automation PR: microsoft#2628
- Fabric release guide: https://msdata.visualstudio.com/A365/_wiki/wikis/Osmos%20Team%20Wiki/130638/SynapseML-Fabric-Release-Guide-v2
- Live v1.1.3 release: https://github.com/microsoft/SynapseML/releases/tag/v1.1.3
## Rationale
The aggregate synapseml artifact is the coordinate users install and the one release notes advertise, while the guide explicitly points maintainers to synapseml-core. Requiring both prevents a GitHub Release from reporting complete when either the public install contract or the guide's Maven evidence is absent.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
gh release view returns nonzero for both a confirmed missing release and transport/authentication failures. This if treats every failure as found=false, so a transient GitHub error can fall through to note generation and a write attempt instead of failing closed (and can race with an existing release that could not be read). Distinguish a confirmed 404 from other failures and stop on all other errors before publishing.
Category: release infrastructure
## Summary
Add source-bound release plans, durable publication and recovery, exact artifact
verification, and guarded pre-merge tag orchestration. Keep public plans and
evidence separate from optional local configuration. Prepare versioned
documentation without promising artifacts that the release does not produce.
## Prompting Intent
Automate repeatable SynapseML releases and prepare a pre-merge 1.2.0 release for
Spark 3.5, 4.0 and 4.1. Keep private integrations out of the critical path and
keep confidential configuration out of public source and workflow inputs.
Preserve human approval, signing, immutable coordinates and branch-specific
runtime behavior. Spark 4.1 PR compatibility replay is advisory, not a waiver
of validation for an actual release candidate.
## Linked Sources
- microsoft#2628
- scripts/release/README.md
- .github/skills/synapseml-release/SKILL.md
- reviews/pr-2628/
- https://docs.github.com/en/rest/commits/commits#list-pull-requests-associated-with-a-commit
## Rationale
Keep the normal master-ancestry rule and add a separately admitted pre-merge
path rather than weakening ordinary publication. Bind approvals, source tags,
producer runs and artifact hashes so retries cannot silently change a release.
Use public allowlists and fixed evidence roles rather than redacting arbitrary
private payloads after serialization.
Support squash and rebase integration through verified canonical PR provenance
without moving tags. Preserve historical documentation and provide guarded
recovery for a new snapshot. Keep previews separate from website deployment.
This commit does not publish 1.2.0. Production remains blocked on the Python
distribution decision and exact-wheel consumer proof across runtimes, followed
by current-head hosted validation and the required human release approvals.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 879c5a1c-4efa-4620-93ea-f8f0052112f1
Category: release infrastructure
## Summary
Check the remote primary, Spark and Python tag family before starting release
preparation. Route existing members to recovery, and fail closed when either
the tag or preparation-branch lookup fails.
## Prompting Intent
Make repeatable SynapseML release preparation safe after interrupted attempts,
without moving immutable tags or treating missing remote access as an empty
namespace. Resolve the current-head review finding on the automation PR.
## Linked Sources
- microsoft#2628 (comment)
- reviews/pr-2628/pr-2628-attempt-5-review-1-gpt-6-astra.md
- scripts/release/README.md
## Rationale
The primary tag can be absent while derivative tags already reserve part of a
release. Query the remote family at the existing early guard rather than
opening another preparation PR and failing later. Preserve remote refs and use
explicit recovery instead of deleting preparation state.
Real local Git regressions cover partial and annotated families, neighboring
versions, existing branches and lookup failures. The follow-up validation
passed 91 tests. Production remains held for the separate Python distribution
decision and consumer verification.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 879c5a1c-4efa-4620-93ea-f8f0052112f1
Category: release infrastructure
## Summary
Default public release plans, preparation and orchestration to master and
spark4.1. Keep Spark 4.0 explicitly selectable without requiring its branch,
candidate validation, policy query or packages for default releases.
Generate release-note installation rows from the validated plan. Keep optional
Spark 4.0 consumer examples and website metadata on their last published
version across repeated default version bumps.
## Prompting Intent
The maintainer requested master / Spark 3.5 and spark4.1 as the default release
targets while continuing the pre-merge release-automation work in PR microsoft#2628.
Preserve immutable approvals, no-write previews, recovery and public-only
workflow boundaries. This change does not authorize production publication.
## Linked Sources
- microsoft#2628
- scripts/release/README.md
- .github/skills/synapseml-release/SKILL.md
- reviews/pr-2628/task-2628-default-targets-attempt-1-review-1-gpt-6-astra.md
- reviews/pr-2628/task-2628-default-targets-attempt-1-review-2-gemini-3.8-flash.md
- reviews/pr-2628/task-2628-default-targets-attempt-1-review-3-claude-opus-5.5.md
- reviews/pr-2628/task-2628-default-targets-attempt-1-review-4-gpt-6-astra.md
- reviews/pr-2628/task-2628-default-targets-attempt-1-review-5-gemini-3.8-flash.md
- reviews/pr-2628/task-2628-default-targets-attempt-1-review-6-claude-opus-5.5.md
## Rationale
Separate new-plan defaults from the complete runtime catalog so saved
three-target plans retain their exact identities and source bindings.
Bootstrap follows its approved plan, while normal tag orchestration requires
a per-dispatch Spark 4.0 opt-in. Repository policy remains a veto only when
that optional target is selected. Accept older stricter ledger records but
reject records that waive a selected target's policy.
Retain optional-runtime installation versions rather than promising artifacts
that the default release will not produce. Explicit Spark 4.0 inclusion still
requires reviewing its source and updating its retained consumer references.
Account for pre-updated destination-version references in the bump
post-condition, and document a runnable opt-in documentation sequence.
Preserve existing default port PRs rather than promising to restack them;
Spark 4.0 tag recovery remains an explicit per-dispatch selection.
Check all optional-runtime artifact references and Python pins together so a
partial documentation edit cannot appear valid. Document early readiness
checks and safe pre-publication back-out without changing immutable sources.
Keep production publication held until the Spark 4.1 Python distribution and
consumer validation requirements are resolved.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 879c5a1c-4efa-4620-93ea-f8f0052112f1
Category: release infrastructure
## Summary
Allow release-note creation only after a completed HTTP 404 lookup.
Leave existing releases untouched on HTTP 200, and stop on every other
status or transport failure. Bound the request and report the failure.
Add executable workflow regressions for success, absence, redirects,
authentication, rate limiting, server failures and incomplete transfers.
Document recovery and record the bounded review passes.
## Prompting Intent
The maintainer authorized additional code commits and pushes to address
the confirmed Copilot release-lookup finding in PR microsoft#2628. Keep this fix
targeted and preserve the separate production Python-wheel gate.
## Linked Sources
- microsoft#2628
- microsoft#2628 (comment)
- .github/workflows/release-notes.yml
- scripts/release/test_release_tag_recovery.py
- scripts/release/README.md
- reviews/pr-2628/task-2628-release-lookup-attempt-1-review-1-gpt-6-astra.md
- reviews/pr-2628/task-2628-release-lookup-attempt-1-review-2-gpt-6-astra.md
- reviews/pr-2628/task-2628-release-lookup-attempt-1-review-3-gpt-6-astra.md
- reviews/pr-2628/task-2628-release-lookup-attempt-1-review-4-gpt-6-astra.md
- reviews/pr-2628/task-2628-release-lookup-attempt-1-review-5-gpt-6-astra.md
- reviews/pr-2628/task-2628-release-lookup-attempt-1-review-6-gpt-6-astra.md
## Rationale
The former CLI exit code conflated a missing release with API or network
failure. A direct authenticated API lookup exposes the HTTP status without
parsing human-readable errors. Its transport exit status must also succeed,
so an incomplete 404 response cannot authorize publication.
Keep the existing approval and evidence gates, publication commands and
release selections unchanged. This commit does not publish a release or
change the Python distribution strategy.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 879c5a1c-4efa-4620-93ea-f8f0052112f1
## Summary
Add runtime-matched Databricks archive generation and immutable publication
to the existing protected public-release job. Gate release completion and
notes on anonymous download hashes matching producer receipts.
Classification: release infrastructure.
## Prompting Intent
Integrate automatic notebook publication into microsoft#2628 so
future releases, including 1.2.0, do not repeat the broken DBC links reported
in microsoft#2346. Preserve existing approvals and release safety
gates. Do not publish 1.2.0 or claim notebook execution was validated.
The maintainer authorized skipping unavailable review models.
## Linked Sources
- User issue and follow-up: microsoft#2346
- Release automation: microsoft#2628
- Operator guide: scripts/release/README.md
- Independent review findings and resolutions: reviews/pr-2628/task-2628-attempt-6-review-*.md
## Rationale
Schema 4 explicitly approves the new archive destination while saved schema-2
documents keep their original digest and obligations. Native Databricks
export/reimport validates content rather than assuming handcrafted ZIPs work.
Publish and anonymously verify DBCs before irreversible PyPI and ESRP work;
an incomplete release can leave an unadvertised archive but cannot overwrite
it. Same-plan retries reuse and revalidate the exact published bytes.
Offline pre-tag notebook checks prevent unsupported source from being tagged.
954 Linux release tests and 12 installation tests passed. The Git-dependent
checkout test passed separately on Windows; optional live SBT was skipped.
Native round-trip validated 56 current notebooks without executing them.
Four available independent reviews completed; two Gemini rounds were skipped
on maintainer instruction. Production release approval remains blocked on the
existing consumer-wheel distribution issue and release-candidate validation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
if entry.is_dir() or entry.filename == "manifest.mf":
continue
This branch has not been deployed
No deployments
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
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.
Summary
Automate repeatable public SynapseML releases for master / Spark 3.5 and
spark4.1. Spark 4.0 remains an explicit opt-in.
What this automates
publication with a durable release ledger.
source commit. Strip saved outputs and verify every notebook through native
Databricks export and reimport.
mmlspark/dbcscontainer. Check anonymous downloads before PyPI and ESRP publication, then
include archive hashes in producer receipts and verified release notes.
approve notebook publication and require archive evidence for completion.
partial or ambiguous submissions. Private integrations are not prerequisites.
HTTP 404 authorizes creating a missing GitHub Release.
For 1.2.0, new plans require
SynapseMLExamplesv1.2.0.dbcandSynapseMLExamplesv1.2.0-spark4.1.dbc. Opting into Spark 4.0 adds its matchingarchive. Future versions derive their archive names from the approved Maven
versions. This addresses the recurring missing archives in
#2346.
The operator guide
documents access prerequisites, approval, notebook preflight and recovery.
Plan approval, signing approval and PR merges remain human actions.
Default version bumps leave optional Spark 4.0 examples on their last release.
Validation and limits
The DBC integration was rebased onto master
bccec7e73d. Range comparisonpreserved all four earlier PR commits.
skipped. The current-checkout notebook test passed separately with Windows
Git because WSL Git cannot open Windows-created worktree pointers.
pinned Black 22.3.0. An earlier pipeline-only run passed 124 checks.
preserving all 1,108 nonempty commands. This used a synthetic
0.0.0archivewithout blob publication or production tags.
addressed. Two unavailable Gemini rounds were skipped at maintainer request.
Review evidence
records findings, fixes and limitations.
Notebook code was not executed on Databricks compute. Native archive
compatibility is not proof that every example runs without service setup.
The integration is pushed as
f4b9473e5751d9ec9c157ac34565405952c17f61.Azure build 238110760
has started for this head after
/azp run. Hosted validation is still pending;earlier-head checks do not validate this integration. Spark 4.1 PR compatibility
replay is advisory, but actual release candidates still require runtime-specific
validation.
Before publishing 1.2.0
This work has not published 1.2.0. Production publication remains blocked
until Python distribution works on both selected runtimes.
The primary PyPI wheel contains master's Python code, while spark4.1 has
additional compatibility fixes. Port-built wrapper tests do not validate the
primary wheel. Select and validate a cross-runtime wheel or matching
runtime-specific wheels, then update consumer instructions and inventory.
This DBC integration adds notebook publication to new approved plans; it does
not resolve the consumer-wheel packaging blocker.
Keep the PR unmerged until the requested pre-merge release trial is complete.