GitHub and NuGet releases

The GitHub delivery target is yesbert/WeavePort. CI verifies documentation and release tooling, and runs the existing frozen-candidate qualification on a standard macOS ARM runner. This is functional qualification, not a hosted performance benchmark or Windows support claim.

Packages and version

The release allowlist in build/release-packages.json contains the four core packages plus WeavePort.Composition, WeavePort.Sdk.Gateway.Client and WeavePort.Sdk.Gateway. Testing remains internal. The three optional packages have a separate API baseline and packed-consumer qualification. Python and TypeScript author SDK publication is separate from NuGet delivery.

The published release version is 0.9.0, licensed under MIT. All seven .NET packages and the exact compatibility matrix use 0.9.0; host API is 2, exclusive native protocol is 1 and concurrent native protocol is 2. Python/TypeScript SDK versions are 0.4.0; the qualified wheel and tarball accompany the GitHub release without claiming PyPI/npm registry publication. Historical internal distribution and measurement evidence retain their original identities. Public releases require complete clean candidate qualification and publication verification; see current release status. A tag override cannot substitute for updating compatibility inputs.

The previous 0.8.0 release report records exact-tag qualification, the prepublication cancellation correction and verified public downloads. The previous 0.7.0 release report records exact-tag qualification, the completed audit and verified public downloads. The 0.5.0 release report records all seven public packages, tag qualification and download verification. The 0.4.0 release report retains the exact qualification, artifact hashes and publication verification.

Trusted Publishing setup

The workflow separates three responsibilities: verification without publication credentials, a gated publish job and a separate release announcement.

Configure these values:

Location	Setting
GitHub Actions repository variable	NUGET_USER=Yesbert
GitHub environment	nuget-org
Environment required reviewer	yesbert
Environment deployment restriction	Tags matching v*
NuGet.org policy owner	The account owning the WeavePort packages
NuGet.org GitHub repository owner	yesbert
NuGet.org repository	WeavePort
NuGet.org workflow filename	release.yml
NuGet.org environment	nuget-org
NuGet.org package pattern	WeavePort.*
NuGet.org scope	Push new packages and package versions

Create the matching policy in the authenticated NuGet.org account. Scope it to the intended WeavePort packages and permit new package IDs when creating the first release. A policy for Stratara does not authorize WeavePort. Follow NuGet Trusted Publishing for current account requirements and policy activation rules. There is no long-lived API-key fallback.

Release procedure

1. Choose and review the public version and license. Update exact compatibility inputs and regenerate LLM documentation. Merge the reviewed change with green CI.
2. Create and push an annotated v<version> tag at that reviewed commit. The tag must exactly match Directory.Build.props; internal suffixes and malformed versions are rejected.
3. The release workflow repeats clean qualification. It checks the qualified commit, package hashes, metadata, readme, source provenance and symbols, then uploads only the original tested allowlisted artifacts.
4. Review the nuget-org deployment. After approval, NuGet/login exchanges GitHub OIDC identity for a short-lived key and publishes the packages and symbols.
5. Only after successful publication does the announce job create the GitHub release; prereleases are marked accordingly. An existing release entry is preserved on rerun.

Branch pushes and pull requests never publish packages. Publication cannot be undone by deleting a Git tag: NuGet versions remain allocated. A partial publish is resumed with the same tested artifacts and --skip-duplicate; investigate any mismatch before rerunning. Never move a released tag to different source.

CI retains qualification logs and manifests for 14 days. Preserve release evidence durably when qualifying a public release. GitHub-hosted runner SDK/runtime identities are recorded by the candidate harness. Docker Desktop on a developer machine is not touched by these workflows.

0.2.0 migration

The pre-1.0 minor release includes breaking host API cleanup: rename ExecutionProtection to ExecutionProtections, and pass requiredProtection before the final cancellationToken in BindAsync and PrewarmAsync (named arguments are recommended). Rebuild consumers and regenerate installation declarations for the exact 0.2.0 core package matrix; the wire protocol and host compatibility level remain 1. Python and TypeScript author SDKs remain 0.1.0.

This release fixes cancellation-source ownership and shutdown/startup races, uses exclusive private native-socket directories, and selects Docker by an absolute trusted CLI path. Set DockerProfile.DockerExecutable for nonstandard CLI installations; PATH lookup is no longer used. All 37 original Sonar issues and both security hotspots were resolved before preparing this release. Platform validation limits remain documented in platform qualification.

The 0.2.0 release report retains publication verification and links to durable package, symbol and qualification assets.

0.2.1 package branding

All core packages embed the existing website logo as their NuGet icon. Release export requires the embedded image to match the repository asset byte for byte. This patch changes package branding and exact compatibility versions; runtime APIs remain unchanged from 0.2.0.

The 0.2.1 release report records exact public package and gallery icon verification, with durable qualification artifacts.

0.3.0 optional MCP tools

Hosting adds explicitly selected local MCP 2025-11-25 and 2026-07-28 tools alongside native plugins. Discovery and calls share worker admission, tenant ownership, deadlines and cleanup. Native remains the default; there is no new MCP runtime dependency. Unsupported result continuations are rejected even if a server also supplies content. See the MCP guide and executable example.

Update all four core packages and exact installation declarations together. Native author SDKs remain 0.1.0 and are still source-built. Hosting uses Microsoft logging/DI abstractions 10.0.12; the optional gateway's build-only Grpc.Tools is 2.84.0. Remote MCP, arbitrary server SDKs and additional platform qualifications are outside this release.

The 0.3.0 release report links the original qualified packages, symbols, test evidence and measurements of the released Hosting assembly.

0.3.1 named MCP methods

Hosting exposes McpMethods.ListTools and McpMethods.CallTool for consumer invocations. Examples and the guide use these constants. Internal MCP identifiers, SDK operations and gateway metadata are centralized without changing wire values. Update the four core packages together to match the exact 0.3.1 compatibility matrix.

0.5.0 composition and gateway packages

Composition adds bound SDK mapping with authenticated remote tenant discovery and observable cleanup failures. Gateway splits hosting from the ASP.NET-independent remote client and adds direct HTTP/2 TLS qualification. See gateway deployment, composition and dependency review. The release audit records the integrated review and qualification boundary. Publication is completed only by the gated release workflow and public package verification.

Run ./scripts/prepare-core-packages.sh to prepare all seven release packages in artifacts/packages, then python3 scripts/verify-optional.py for packed optional consumers. The clean candidate performs this qualification against frozen artifacts. Core installation declarations remain the three core host identities plus author SDKs; optional packages are never mandatory declaration entries.

Before tagging, review the seven-package allowlist and NuGet Trusted Publishing policy for the three new IDs. Export the original qualified packages and symbols; do not rebuild after qualification. After publication, verify all seven public package payloads against the candidate and retain the report.

0.4.0 approved session reuse and fair scheduling

The four core packages add memory-led fair scheduling, explicit operator-approved reuse, cleanup capability checks, idle retention and diagnostics. C# 0.4.0 and Python/TypeScript 0.2.0 SDKs register session-owned resources and attempt reverse-order cleanup. Customer-bound execution remains the default. Hidden globals and unregistered background work remain a documented residual risk under approval; see best practices and runnable examples.

Clean candidate qualification now includes source and packed reuse consumers, matching Hosting/SDK DLL hashes, and all three maintained author examples. Download the exact Python wheel and TypeScript tarball from the 0.4.0 release assets and install them with python -m pip install ./weaveport_sdk-0.2.0-py3-none-any.whl and npm install ./weaveport-sdk-0.2.0.tgz. These packages are not announced as registry publications.

The implementation evidence retains pre-release cold/warm measurements with their original hashes and version labels. It does not establish maximum Docker capacity. Docker cold-start and repeated image resolution at registration remain explicitly separate from warmed invocation throughput.

The 0.4.0 audit records release findings and their corrections. Publication evidence is added only after successful gated delivery.

0.6.0 unified execution and installed clients

Use one PluginHost with either fail-fast or bounded fair admission. Replace ScheduledPluginHost/RegisterAsync with PluginHost(SchedulingOptions)/BindAsync; set Reconstructible only for bindings whose idle state can be discarded. Callback nesting is refused consistently. Shared is explicit operator-approved resident concurrent execution, with protocol 2 and invocation-scoped identity, cancellation and failure handling. Exclusive ownership retains protocol 1.

Catalog discovery and PluginApproval remove manual launch-profile construction from the recommended path. Hosting now depends on Sdk.Client to return the same bound client type for installed exclusive and shared plugins. Upgrade the entire selected 0.6.0 .NET family and regenerate installation declarations for host API 2 and matching 0.3.0 Python/TypeScript artifacts. A launch selects one native protocol; shared launches cannot also advertise serial ownership.

Exclusive streams hold an operation-wide worker lease, flush available items and use separate exchange/total deadlines. Composition.CollectAsync reads plugin-originated bytes in bounded blocks locally or through the Gateway. See shared execution, installed clients, source sample and the audit. The 0.6.0 release report records exact-tag qualification, the static audit, benchmark limits and verified publication evidence.

0.7.0 portable installations and consumer diagnostics

Hosting now seals deterministic schema-2 bundles through a public .NET API with an embedded compatibility policy. Runtime selection follows hashed .NET, Python and Node declarations; unchanged bundles can move between compatible runtime installations without executable-hash equality. Schema 1 and opt-in strict executable hashes retain their checks. Exact package versions and manifest pins still require deliberate offline migration.

ListAll/ListAllAsync report every plugin directory, including refusal diagnostics. The author SDK offers VersionFromAssembly, and startup mismatches expose expected/advertised versions with version-mismatch and no dispatch. CallWithMetadataAsync pairs typed or JSON values with nullable host timing locally and over the gateway. This adds optional protobuf fields without changing native protocol numbers. Default author version remains 1.

The release audit records corrections and evidence. The release record retains successful publication and verification of all seven NuGet packages and 16 GitHub downloads.

0.8.0 failure contracts and code quality

Release 0.8.0 adds structured failure metadata (PluginFailure, InvocationResult.Failure, PluginCallException.Failure), stable exception codes and the opt-in WorkerPoolOptions.DetailedFailureSink. Existing .NET signatures remain available. Python and TypeScript author SDKs advance to 0.4.0; download their wheel/tarball from this release rather than reusing 0.3.0 artifacts. The internal reorganization covers runtime responsibilities, samples, tests and tooling without introducing a new runtime dependency.

Migration from 0.7.0

• Upgrade all selected .NET packages together to 0.8.0 and author SDKs to the exact versions in the compatibility matrix. Rebuild/reseal installations offline; the new manifest identity requires deliberate application-pin migration. Keep original deployments for existing recovery pins. Do not edit a sealed manifest in place.
• Handle failures through Failure?.Code ?? ErrorCode with an unknown-code fallback. Gateway failures now use bounded platform/transport codes instead of gRPC detail text; unrecognized peer values become unknown-error. Callers matching previous text/status values must update their handling. Codes never grant permission to retry; retain MayHaveExecuted and reconcile uncertain effects.
• Review cancellation catches. A gateway Cancelled status produces OperationCanceledException only when the supplied local token is requested; otherwise it is a PluginCallException with code cancelled. Host cancellation attribution distinguishes caller cancellation, host shutdown, owned deadlines and unrelated internal cancellation.
• Execution and registered cleanup failures retain their causes; cleanup must not replace the primary failure. Python keeps SessionCleanupError and exposes its retained causes. Code that assumed only the last cleanup failure should inspect the documented metadata/aggregate causes.
• Default logs remain safe and source-generated. Event IDs 1001–1007 remain allocated; event 1008 reports diagnostic delivery failure. Invocation event 1003 includes code and cleanup outcome. Raw local exception details require an explicitly configured protected sink. Exception messages are not machine contracts.

Host API 2 and native protocols 1/2 remain unchanged. Gateway Reply fields 10–13 are additive; old peers may omit failure details. This does not qualify arbitrary mixed package families. See failure codes, runtime diagnostics and the release evidence. No new Docker containment or capacity/performance guarantee is introduced.

0.9.0 trusted publishers and reflection-free installation JSON

Version 0.9.0 is published. See the release record.

Installation sealing, requirements and compatibility JSON now use explicit generated metadata with reflection disabled. Existing manifest serialization remains byte-compatible for unchanged inputs; this does not promise general NativeAOT support.

Hosts can opt into PluginPublisherPolicy.RequireTrustedPublisher with immutable trusted RSA public keys. Offline tooling signs exact schema-2 manifest bytes with RSA-PSS/SHA-256 in installation.signature.json. Catalog resolution, listing and activation reject missing, malformed, unknown-publisher or invalid signatures before worker execution. Existing constructors retain integrity-only behavior. See publisher trust and the compiled examples.

Migration:

• Upgrade all selected .NET packages together to 0.9.0. Python and TypeScript author SDKs remain 0.4.0; host API 2 and native protocols 1/2 are unchanged.
• Rebuild and reseal installations offline against the exact 0.9.0 compatibility matrix. Sign after sealing and verify before deployment. Changed manifest bytes require a new signature and a deliberate application-pin migration; preserve old deployments for existing recovery pins.
• Configure trusted public keys in the host through a separate trusted channel. Private signing keys belong in the release pipeline. Strict publisher verification requires schema 2; legacy installations need offline migration.
• Trust is catalog-wide. Replacing a policy does not revoke existing handles or running workers: dispose them and resolve again under the replacement policy. Signatures do not provide sandboxing, namespace authorization or rollback protection.

No new runtime dependency, protocol version, platform support qualification or performance guarantee is introduced. Publication requires a reviewed preparation merge, green checks and separate authorization for tagging and the protected release workflow.