Pulp Engine Document Rendering
Get started
Release v0.64.0

Release v0.64.0

Date: 2026-04-11

Theme

Commercial Distribution.

Pulp Engine is a commercial product sold to developers, dev teams, and enterprise. The earlier SDK work (v0.61.0 Python, v0.62.0 .NET, v0.63.0 Go) shipped the generator-driven SDK track but didn’t fully close the commercial-distribution loop: @pulp-engine/sdk was workspace-only (customers couldn’t npm install), the Go SDK relied on a git subdirectory-tag scheme that doesn’t work against a private source repo (proxy.golang.org can’t fetch from private repos), and Stage 3 Java was planned to go through GitHub Packages with a read:packages PAT — fine for open-source consumers, unacceptable for enterprise security teams.

v0.64.0 closes all three gaps at once so the commercial SDK story is consistent across all five languages: every paying customer can install any Pulp Engine SDK with zero access to the private source repo, zero authentication configuration, and zero custom registry setup.

Stage 3 Java (v0.65.0) now ships via Maven Central, not GitHub Packages.

Highlights

1. TypeScript SDK publishes to public npm — @pulp-engine/sdk + @pulp-engine/template-model

Two npm packages, published in lockstep from the same workflow.

  • @pulp-engine/sdk — the full API client. Install via npm install @pulp-engine/sdk. Companion to the existing @pulp-engine/sdk usage inside the monorepo — no code changes for workspace consumers, but the same package is now installable by any external customer.
  • @pulp-engine/template-model — typed shapes for Pulp Engine template definitions. Zero runtime deps. Used by @pulp-engine/sdk as a transitive dependency, AND usable standalone for template authoring / validation / code generation. Previously a private workspace package at version 0.1.0; now public and bumped to the lockstep version.

Publish order is load-bearing. The new .github/workflows/publish-sdk-typescript.yml workflow publishes @pulp-engine/template-model first, then @pulp-engine/sdk, because pnpm’s workspace:* → semver rewrite means the published @pulp-engine/sdk package.json declares "@pulp-engine/template-model": "0.64.0" — which must exist on the registry before the sdk publish can be consumed.

Verified: pnpm pack of @pulp-engine/sdk produced a tarball with "@pulp-engine/template-model": "0.64.0" in the rewritten package.json (no workspace:*). The rewrite works automatically on publish.

One-time operator setup required for first publish: create the @pulp-engine org on npm (or claim the scope), configure npm Trusted Publishing for both packages OR save an NPM_TOKEN secret, and create the npm GitHub environment. Full runbook in packages/sdk-typescript/RELEASING.md.

2. Go SDK publishes to a public mirror repo — github.com/TroyCoderBoy/pulp-engine-go

The Stage 2 subdirectory-tag scheme (packages/sdk-go/vX.Y.Z) is retired because it only works against public source repos. The main Pulp Engine repo is private (commercial source), so proxy.golang.org can’t fetch from it — and handing customers GOPRIVATE + repo collaborator access isn’t a viable commercial distribution model.

v0.64.0 ships a public mirror repo at github.com/TroyCoderBoy/pulp-engine-go containing only the generated Go SDK:

  • Generated .go source: api_*.go, model_*.go, client.go, configuration.go, response.go, utils.go (~127 files)
  • go.mod, go.sum, version.go, health_smoke_test.go
  • Per-endpoint/model reference markdown under docs/
  • Standalone README.md (generated by the sync script, NOT copied from the main repo)
  • LICENSE

What is NOT copied to the mirror: the main repo’s apps/api/, apps/editor/, apps/preview/, every packages/*-renderer/, packages/template-schema/, packages/data-adapter/, packages/plugin-api/, templates/, docs/, scripts/, workflow files, CI config, Dockerfiles, proprietary algorithms, business logic — none of it. The mirror is strictly the SDK surface that a competitor could reproduce mechanically by running openapi-generator against the public openapi.json spec themselves. Zero IP exposure beyond what’s already visible to any customer calling the Pulp Engine API.

Customer install becomes:

go get github.com/TroyCoderBoy/pulp-engine-go@v0.64.0

Zero auth, no GOPRIVATE, no repo access. The standard Go module proxy (proxy.golang.org) serves the mirror because it’s public.

How the sync works

  • packages/sdk-go/ in the main repo stays as the source of truth. The main repo still contains the full Go SDK tree for generation, local builds, and the smoke test.
  • go.mod module path is pinned to github.com/TroyCoderBoy/pulp-engine-go via a new post-processing step in scripts/generate-sdks.ts. Go doesn’t require file-path/module-path alignment for same-package imports, so the smoke test at packages/sdk-go/health_smoke_test.go still works locally despite the file path not matching the declared module path.
  • scripts/sync-sdk-go-mirror.ts (new) is the release-time sync. Clones the mirror repo via an authenticated PAT, wipes the tree, copies a curated file set, writes a standalone README, commits, creates tag vX.Y.Z (no subdirectory prefix), and pushes. Idempotent: same content at same tag = no-op. Different content at same tag = loud failure per tag-immutability policy.
  • .github/workflows/publish-sdk-go.yml was rewritten for the mirror-sync approach. The Stage 2 subdirectory-tag logic is gone; the new flow runs check-ci → build-and-smoke (same pattern as .NET) → sync-mirror → go mod download -x proxy verification.
  • Dry-run mode in sync-sdk-go-mirror.ts lets you preview the 131 files that will be copied + the generated README content without touching the mirror repo. Verified locally during Stage 2 rework.

Why two repos instead of making the main repo public

Making Pulp Engine itself public would be a product-level decision with significant commercial implications — not just an SDK convenience. The mirror approach preserves the current commercial model (private source, paid product) while giving Go customers a zero-friction install. This is the same pattern HashiCorp, MongoDB, Datadog, and most commercial SaaS vendors use for their Go SDKs.

3. Stage 3 Java re-planned: Maven Central, not GitHub Packages

The original Stage 3 plan had Java publishing through GitHub Packages Maven with a consumer-side read:packages PAT. That was the right call for an open-source SDK with low-intensity users, but it’s the wrong call for a commercial product: enterprise security teams will not allow their devs to provision PATs against a vendor’s GitHub org, and the consumer-side setup tax is a constant friction point for every new team.

The commercial recommendation flips to Maven Central.

AspectOriginal Stage 3 planCommercial Distribution (v0.65.0 Stage 3)
v1 targetGitHub Packages MavenMaven Central via Sonatype Central Publisher Portal
Auth on publishGITHUB_TOKENSonatype credentials + GPG signing key in repo secrets
Consumer frictionPAT + custom repo block + settings.xmlZero — <dependency> block, standard Maven resolution
Operator one-time costZero1-3 days — Sonatype account, domain verification, GPG key, Central Publisher Portal registration

Group ID options (operator must pick before Stage 3 starts):

  • Preferred: io.pulp-engine — requires owning the pulp-engine.io domain for Sonatype’s domain-verification step.
  • Alternative: com.github.troycoderboy.pulp-engine — Sonatype allows this pattern via GitHub account ownership, no domain purchase required.

Artifact id: pulp-engine-sdk

Everything else from the original Stage 3 plan (generator-driven source under packages/sdk-java/, smoke-test pattern, lockstep versioning, CI freshness gate, .openapi-generator-ignore determinism) stays. Only the publishing target changes.

The updated plan is at the bottom of crispy-percolating-squid.md under “Commercial Distribution addendum”.

Customer-facing changes summary

Languagev0.63.0 statev0.64.0 commercial install
TypeScriptWorkspace-only, unpublishednpm install @pulp-engine/sdk
Pythonpip install pulp-engine (shipped v0.61.0, blocked by billing)Unchanged
.NETdotnet add package PulpEngine.Sdk (shipped v0.62.0, blocked by billing)Unchanged
GoPrivate-repo subdirectory tag + GOPRIVATE + credentialsgo get github.com/TroyCoderBoy/pulp-engine-go@v0.64.0 — zero auth
JavaPlanned: Stage 3, v0.65.0Stage 3, v0.65.0 — now via Maven Central

What’s in the new pulp-engine-go public repo

Created at https://github.com/TroyCoderBoy/pulp-engine-go during v0.64.0 prep. Currently empty. It stays empty until one of two things happens:

  1. The publish-sdk-go.yml workflow runs successfully on the v0.64.0 tag push. Currently blocked by the same GitHub Actions billing issue that’s held v0.61.0 → v0.63.0 publishes. When billing is resolved and the workflow re-runs via workflow_dispatch, the sync job will populate the mirror with the v0.64.0 content automatically.
  2. The operator runs the sync script manually against the mirror with a PAT. This is documented in packages/sdk-go/RELEASING.md as an alternative for the pre-billing-resolution interim. The command is: 
    PULP_ENGINE_GO_MIRROR_TOKEN=<pat_with_write_access_to_pulp-engine-go> \
  pnpm exec tsx scripts/sync-sdk-go-mirror.ts --version 0.64.0

Either path produces the same result: the mirror gets populated with v0.64.0 generated source + standalone README, a v0.64.0 tag is created on the mirror, and customers can go get github.com/TroyCoderBoy/pulp-engine-go@v0.64.0 immediately after.

scripts/check-version.mjs lockstep now spans 9 packages

@pulp-engine/template-model joined the lockstep in v0.64.0 because it’s now publicly published alongside @pulp-engine/sdk. Previously it sat at 0.1.0 as a private workspace package; the bump from 0.1.0 → 0.64.0 is a one-time “joining the lockstep” jump. Future releases move it with everything else.

The 9 lockstep sites are now: package.json, apps/api, apps/editor, apps/preview, packages/sdk-typescript, packages/template-model, packages/sdk-python (via pyproject.toml), packages/sdk-dotnet (via .csproj <Version>), packages/sdk-go (via version.go + go.mod path verification).

Deliberate deferrals (out of scope for v0.64.0)

  • Java SDK itself. Ships in v0.65.0 as Stage 3, now via Maven Central. Sonatype onboarding should start during v0.64.0 deployment so it’s ready when Stage 3 work begins.
  • Deleting the v0.63.0 subdirectory-tag approach from git history. The subdirectory-tag scheme was never actually used for a production publish (the tag packages/sdk-go/v0.63.0 was never created because the publish workflow was blocked by billing). No cleanup needed; the v0.63.0 release commit stays in history as “what we planned but didn’t ship.”
  • Maven Central operator onboarding. Sonatype account creation, domain verification, GPG key generation, and Central Publisher Portal registration are operator tasks that will happen before Stage 3 starts.

Verification done on this commit

✅ Public pulp-engine-go repo created           (empty, public, gh repo create)
✅ pnpm sdk:generate (both SDKs at 0.64.0)   (go.mod: github.com/TroyCoderBoy/pulp-engine-go,
                                                version.go: const Version = "0.64.0",
                                                .csproj: <Version>0.64.0</Version>)
✅ docker run golang:1.23-alpine go build    (BUILD_OK)
✅ docker run golang:1.23-alpine go vet      (VET_OK)
✅ pnpm sdk:generate --dry-run                (sync script enumerated 131 files correctly)
✅ pnpm --filter @pulp-engine/template-model build  (clean)
✅ pnpm --filter @pulp-engine/sdk build         (clean)
✅ pnpm pack @pulp-engine/sdk                    (rewrote workspace:* → "0.64.0" for template-model dep)
✅ node scripts/check-version.mjs              (9 packages OK; tag mismatch is pre-commit expected)

Known residuals

  • Publish workflows still blocked by GitHub Actions billing. Same block that held v0.61.0 PyPI, v0.62.0 NuGet, and v0.63.0 (no mirror). v0.64.0 will trigger FIVE publish workflows on tag push (python, dotnet, go, typescript, release docker image) — all will hit the same billing gate. The moment billing is resolved, ALL pending releases can re-run via workflow_dispatch simultaneously.
  • First-publish operator actions stack up as:
    1. Fix GitHub Actions billing.
    2. Create @pulp-engine npm org OR configure npm Trusted Publishing / NPM_TOKEN.
    3. Create PULP_ENGINE_GO_MIRROR_TOKEN PAT with write access to pulp-engine-go.
    4. Save all the secrets in repo settings.
    5. Re-run the five blocked publish workflows in any order.
  • Sonatype onboarding for Stage 3 Java should begin during v0.64.0 deployment so domain verification is complete by the time Stage 3 starts. 1-3 days calendar time.
  • Mirror repo is currently empty. It stays empty until the sync script runs for the first time — either via the re-enabled workflow or via manual operator invocation per packages/sdk-go/RELEASING.md.
← Back to releases