Release

At a glance

NextPDF Enterprise models a release as typed value objects — a release manifest, per-artifact manifests, build profiles, distribution channels, and access boundaries — and derives a publishing plan that routes each artifact to the correct channel and access boundary.

Availability & licensing

This capability ships in NextPDF Enterprise (nextpdf/enterprise) and activates with an Enterprise-tier license envelope. A deployment without that entitlement does not load the capability’s classes. Compare editions and get a license.

Install

composer require nextpdf/enterprise:^3

Conceptual overview

ReleaseManifest is the immutable top-level document for a version. It records the semantic version, the source commit, the build timestamp, the list of per-artifact manifests, and optional supply-chain evidence paths (SBOM, GPG signature, checksums). Its schema version follows minor-for-additive, major-for-breaking.

ArtifactManifest records one built artifact: its canonical filename, version, source commit, target edition, delivery mode, encoding technology, distribution channel, target PHP version, SHA-256 digest, optional encoding expiry, and build timestamp. EncodingTechnology distinguishes the tool used to encode an artifact from whether it was encoded at all; a cleartext artifact always has None.

DistributionChannel separates two concerns explicitly: an artifact origin (binary storage) and a package consumption layer (the registry a composer require reads). AccessBoundary determines who may access an artifact — paid customers, time-limited evaluation, or internal CI/QA/staging that is never customer-facing — and every boundary requires authentication.

PublishingPlan is derived from the build profiles and the release manifest. Each profile resolves to publishing targets: an artifact-origin target and a consumption-layer target, with the correct access boundary applied so paid and evaluation artifacts are routed to the right place.

Why it works this way

The load-bearing decision is to model a release as immutable typed value objects, not loose configuration. Artifact origin and consumption layer are distinct enum-typed concerns, and access boundaries are explicit. So a misrouted artifact — an internal build placed on a customer channel — surfaces as a modeling error, not a silent production mistake. The plan stays derived rather than authoritative: it names intended targets while your release tooling performs the transport. The same objects resolve through the Core contract, so a consumer that upgrades edition changes no calling code. That continuity is the point of an open-core boundary — you buy the Enterprise surface, not a rewrite. Design background: Open core, no lock-in.

API surface

Class	Responsibility
ReleaseManifest	Immutable top-level release document.
ArtifactManifest	Per-artifact metadata and verification fields.
BuildProfile	A build configuration to publish.
DistributionChannel	Origin vs consumption-layer channel enum.
AccessBoundary	Paid / Evaluation / Internal access enum.
EncodingTechnology	Encoding tool enum (e.g. encoded / none).
PublishingPlan / PublishingTarget	Derived plan and per-target routing.

Code sample — Quick start

use NextPDF\Enterprise\Release\PublishingPlan;

$plan = PublishingPlan::fromProfiles($profiles, '3.1.0');

Code sample — Production

use NextPDF\Enterprise\Release\PublishingPlan;
use NextPDF\Enterprise\Release\PublishingEnvironment;

$plan = PublishingPlan::fromProfiles(
    $profiles,
    '3.1.0',
    PublishingEnvironment::Production,
);

foreach ($plan->targets as $target) {
    $logger->info('release.target', [
        'version' => $plan->version,
        'channel' => $target->channel->value,
    ]);
}

Edge cases & gotchas

• The artifact origin and the consumption layer are distinct channels. The origin stores the binary; the consumption layer serves the metadata that points to it. Do not conflate them when reasoning about where a composer require resolves.
• A cleartext artifact always reports EncodingTechnology::None; the encoding-technology field answers “which tool”, not “was it protected”.
• Internal access boundary artifacts are never customer-facing; routing them to a customer channel is a configuration error this model is designed to make explicit.
• The publishing plan is derived, not authoritative for transport — it describes intended targets; the actual upload is performed by your release tooling.

Performance

Plan derivation is linear in the number of build profiles and produces a small number of targets per profile. The value objects are immutable and cheap to construct.

Security notes

The release manifest carries supply-chain evidence paths (SBOM, GPG signature, checksums). This module records and routes those references; it does not itself produce signatures or attest provenance. Treat the manifest as metadata to be verified by your release pipeline, not as proof on its own.

Data residency & PII mitigations

Release manifests contain build and artifact metadata, not personal data. Apply your normal controls to artifact storage.

Safe telemetry & log scrubbing

Release logs should record version and channel, not signing key material or internal storage paths.

Conformance

No standards conformance is claimed for this module; it is a release-modeling layer. Supply-chain evidence (SBOM, signatures, checksums) is referenced by the manifest and produced and verified by your release tooling.

FIPS-mode behavior

This module performs no cryptographic operations. GPG signing and checksum generation are performed by external release tooling and only referenced here.

Threat model

Inputs are caller-supplied build profiles and manifest data. The model makes the origin-vs-consumption and access-boundary distinctions explicit so misrouting (for example exposing an internal artifact) is a visible modeling error rather than a silent one.

Behavior contract

• ReleaseManifest is the immutable top-level document for a version; its schema version follows minor-for-additive, major-for-breaking.
• DistributionChannel keeps artifact origin and package consumption layer as distinct concerns; conflating them is a modeling error this type makes explicit.
• AccessBoundary distinguishes Paid / Evaluation / Internal, and every boundary requires authentication; an Internal artifact is never customer-facing.
• PublishingPlan is derived from build profiles and the release manifest; it describes intended targets and is not authoritative for transport.

Publication boundary

This page documents externally observable behavior and the supported public API surface only. Internal namespace paths, helper classes, mechanism tables, runbook filenames, and ticket prefixes are out of scope.

Core fallback

NextPDF Core has no release-modeling layer. A Core-only consumer that needs release manifests, build profiles, or a publishing plan must model them itself.

Pro fallback

NextPDF Pro does not provide the typed release manifests, build profiles, access boundaries, or the derived publishing plan; they ship in the nextpdf/enterprise package only. A Pro-only deployment has no Enterprise component to satisfy a release-modeling request. See the Enterprise overview for the Enterprise surface.

Enterprise boundary note

The manifest schema, the origin-vs-consumption distinction, and the access-boundary routing are described at the behavior level only. The internal channel-resolution tables and the internal publishing-target wiring are out of scope for the public surface and are not reproduced here.

Deployment boundary

The publishing plan is derived metadata, not the transport: the actual artifact upload is performed by your release tooling. Supply-chain evidence (SBOM, GPG signature, checksums) is referenced by the manifest and produced and verified by your release pipeline, not by this module. Routing, credentials, and storage for each channel are the operator’s responsibility.

Legal-compliance boundary

This page describes a release-modeling layer. It records and routes supply-chain evidence references; it does not itself produce signatures, attest provenance, certify a release, or constitute legal advice. Treating the manifest as proof on its own is incorrect; verification is performed by your release pipeline. Judging whether a release meets your contractual or regulatory obligations is your responsibility.

See also

• Release reference
• Enterprise overview
• License activation
• Core vs Pro vs Enterprise feature matrix