Validate spatial-types 1.0.0 release readiness

As a maintainer of spatial-types,
I want to perform a final release-readiness validation of the 1.0.0 candidate,
so that the first stable release is published only when its package, supported dependencies, public API and integration requirements have been verified as a coherent whole.

Context

spatial-types 1.0.0 establishes the first stable release of the library.

Before the 1.0.0 tag can be created, the complete release candidate must be validated in the same state that is intended for publication.

This Story is the final release gate.

It does not define new functionality, redesign public contracts or resolve normative questions.

The normative conformance review and the public contract stabilization review must already be complete.

The purpose of this Story is to demonstrate that the resulting package can be installed, tested and consumed according to the compatibility commitments established for 1.0.0.

Prerequisites

Before this Story can be completed:

• all geometry types required for the 1.0.0 scope must be fully implemented;
• the supported Symfony Validator versions must be established and validated;
• the normative conformance review must be complete;
• all blocking normative findings must be resolved;
• the public API review must be complete;
• internal symbols must be identified;
• all blocking public-contract findings must be resolved;
• the intended 1.0.0 API must be considered stable.

This Story must not be used to bypass an incomplete prerequisite.

Release Candidate

Validation must be performed against the exact source state intended to become 1.0.0.

The release candidate must not depend on uncommitted changes, local-only configuration or development artifacts that are unavailable to consumers.

The package metadata and Composer configuration must represent the dependencies and compatibility requirements intended for the stable release.

Clean Installation

The package must be validated from a clean dependency state.

A fresh Composer installation must succeed using the dependency constraints declared by the package.

The validation must demonstrate that installation does not accidentally depend on:

• an existing local vendor directory;
• a developer-specific Composer configuration;
• undeclared packages;
• undeclared PHP extensions;
• repository overrides required only by the maintainer environment;
• local path repositories that would not be available to normal consumers.

The Composer package definition must be valid for publication as longitude-one/spatial-types.

Dependency Compatibility

The supported dependency ranges declared by spatial-types must be consistent with the compatibility guarantees established for 1.0.0.

Representative supported dependency combinations must be validated.

This includes the supported Symfony Validator generations defined by the dedicated compatibility Story.

The validation must confirm the actual dependency versions installed for each tested compatibility configuration before the test suite is executed.

Unsupported dependency versions must not be implied by overly broad Composer constraints.

Automated Validation

The complete automated test suite must pass against the release candidate.

All quality checks required by the repository must pass.

The validation must use the same source state intended for the release.

No test may require undocumented local configuration to pass.

Existing CI workflows required for the project must succeed on the release candidate.

Public API Consumer Validation

The stabilized Public API must be exercised from the perspective of an external consumer.

The validation must demonstrate that representative spatial objects can be created and manipulated using only supported Public API symbols.

The consumer validation must not rely on:

• @internal symbols;
• classes under an Internal namespace;
• implementation details not included in the supported API;
• test-only helpers;
• direct access to private implementation state.

The validation must include representative use of the geometry types required for the 1.0.0 scope, including CIRCULARSTRING and COMPOUNDCURVE.

Internal Boundary Validation

The final release candidate must preserve the Public API/Internal API boundary established by the contract review.

Known external-consumer scenarios must not require @internal symbols.

LongitudeOne packages required by the targeted 1.0.0 ecosystem must not depend on spatial-types internal symbols as hidden compatibility contracts.

A dependency on an internal symbol discovered during this validation is a release blocker unless the dependency is removed or the symbol is deliberately reconsidered through the public-contract review.

LongitudeOne Integration

The release candidate must be validated against the LongitudeOne use cases that motivate the 1.0.0 release.

In particular, spatial-types must provide the stable spatial objects required to continue the targeted EWKT decoding work in spatial-decoder.

The validation must confirm that CIRCULARSTRING and COMPOUNDCURVE can be consumed through the stabilized Public API without relying on internal implementation details.

This validation concerns the integration contract provided by spatial-types.

Implementation or completion of the EWKT decoder itself remains outside the scope of this Story.

Package Metadata

Before release, the package metadata must be reviewed for consistency with the intended stable package.

The review must include, where applicable:

• package name;
• PHP version constraint;
• required PHP extensions;
• production dependencies;
• development dependencies;
• autoload configuration;
• development autoload configuration;
• package metadata relevant to Composer;
• repository files required by consumers.

The release package must not expose accidental dependencies on development-only resources.

Blocking Findings

A failure discovered during this Story must be classified according to its origin.

A packaging, dependency declaration, CI or release-configuration defect may be corrected as part of release preparation when it does not alter the approved spatial semantics or stabilized Public API.

A finding that requires:

• changing approved normative behavior;
• redesigning a Public API contract;
• exposing an internal implementation detail;
• introducing a backward-incompatible contract change;
• reconsidering a decision made by a prerequisite Story;

must not be silently resolved within this Story.

The relevant prerequisite review must be reopened or a blocking issue must be created and resolved before release readiness can be approved.

Acceptance Criteria

Prerequisites

• All Stories required for the spatial-types 1.0.0 scope are complete.
• The normative conformance review is complete and has no unresolved blocking findings.
• The public contract review is complete and has no unresolved blocking findings.
• The intended Public API is considered stable.

Installation and package

• The release candidate can be installed from a clean Composer dependency state.
• Installation does not rely on undeclared dependencies or PHP extensions.
• Installation does not rely on maintainer-specific Composer configuration.
• The Composer package definition is valid for longitude-one/spatial-types.
• Production and development dependencies are correctly separated.
• Autoload configuration is valid for the release package.
• Package metadata is consistent with the intended 1.0.0 release.

Dependency compatibility

• The declared dependency constraints correspond to the compatibility policy approved for 1.0.0.
• Representative supported dependency configurations are successfully installed and tested.
• Supported Symfony Validator generations are validated according to the dedicated compatibility Story.
• The actual dependency versions used by compatibility tests are verified.
• Composer constraints do not intentionally claim compatibility with known unsupported versions.

Automated validation

• The complete automated test suite passes on the release candidate.
• All repository quality checks pass.
• Required CI workflows pass on the release candidate.
• Tests do not depend on undocumented local configuration.

Public API validation

• Representative external-consumer scenarios use only the stabilized Public API.
• Representative supported spatial objects can be created and manipulated without internal symbols.
• CIRCULARSTRING can be consumed exclusively through supported Public API contracts.
• COMPOUNDCURVE can be consumed exclusively through supported Public API contracts.
• No @internal symbol is required by the validated external-consumer scenarios.

LongitudeOne integration

• The Public API provides the spatial objects required for the targeted EWKT decoder work.
• The targeted spatial-decoder integration does not require access to spatial-types internal symbols.
• No known cross-package dependency required for the targeted 1.0.0 ecosystem violates the Public API/Internal API boundary.

Release gate

• No unresolved release-blocking defect remains.
• No unresolved finding requires a normative decision.
• No unresolved finding requires redesign of a stabilized Public API contract.
• The validated source state is the source state intended to receive the 1.0.0 tag.
• spatial-types is ready to be released as 1.0.0.

Out of Scope

This Story does not:

• introduce new spatial types;
• extend the functional scope of 1.0.0;
• perform a new normative conformance review;
• redesign the stabilized Public API;
• implement EWKT decoding;
• add functionality solely because it could be useful in a future minor release;
• require implementation of spatial types intentionally deferred to the 1.x lifecycle;
• publish the release itself.

A missing feature that is intentionally outside the approved 1.0.0 scope is not a release blocker.

Completion Principle

This Story is complete when the exact spatial-types source state intended for 1.0.0 has been demonstrated to be installable, testable and consumable within the approved compatibility boundaries.

Completion means that no known blocking issue remains between the validated source state and creation of the 1.0.0 release tag.