Publish SDKs to registries
Start in your project's SDK Studio. Preview the generated code and download an artifact before connecting a repository. Publishing requires an eligible project and completed setup; being able to open Studio does not grant publishing access.
First release
Section titled “First release”- Choose a target and review its package name and configuration.
- Select Link a repository. Choose the GitHub account and repository. A dedicated repository makes the generated changes easier to review.
- Read the proposed file list. Linking can add generated code, workflows, provenance metadata, API documentation and an agent skill. A nonempty repository requires acknowledgement; resolve any reported ownership conflict first.
- Follow Registry setup. Confirm the checklist against the provider's real settings before marking a step done.
- Enable publishing when you are ready. The repository preference applies to the next eligible release run; it does not publish an artifact by itself.
- Review the generation pull request. After it lands, follow the release pull request, tag and workflow from the release view.
- Wait for registry observation. A successful workflow or received callback alone does not establish that the intended version is available.
Reading release status
Section titled “Reading release status”| State | What to do |
|---|---|
| Generation PR open | Review the code and required checks. |
| Release PR open | Review the proposed version and release notes. |
| Released, no receipt yet | Follow the linked run; Doctorine is checking delivery. |
| Published and observed | The provider has confirmed the intended publication. |
| Partially published | Inspect each target; retry only unfinished children. |
| Published but unattributed | A version exists without sufficient evidence tying it to this release. Investigate before counting it as success. |
| Observation diverged | The callback and provider disagree. Follow Troubleshooting. |
Updating an SDK
Section titled “Updating an SDK”Update the API/configuration and rebuild the affected target. Review the next generation PR before releasing. Keep custom changes on the configured base branch; see Custom code.
Automatic merge settings are separate from publishing consent. Off leaves merges manual; non-breaking limits the eligible changes; all can admit breaking changes without a human merge decision. Repository protections and the reported protection checks still apply. Unknown bypass/protection status requires manual review.
Use Release-As only to request a deliberate version for the bound release. Read the confirmation and pending state; it is not a way to overwrite an existing registry version or reuse a release tag.
Disabling Doctorine publishing does not remove packages already released. Repository administrators retain control of their own workflows and registry credentials.