1. Overview
2. Release Philosophy
3. Current Release Configuration
4. Versioning Strategy
5. Release Types
6. Release Lifecycle
7. Release Planning
8. Release Readiness Criteria
9. Version Preparation
10. Changelog Management
11. Testing and Quality Gates
12. Compatibility Validation
13. Security and Dependency Review
14. Building Python Packages
15. Package Artifact Verification
16. Clean Environment Installation
17. TestPyPI Validation
18. Production PyPI Publishing
19. Git Tags and GitHub Releases
20. Release Notes
21. Release Automation
22. Rollback and Incident Response
23. Post-Release Verification
24. Maintainer Responsibilities
25. Release Checklist
26. Troubleshooting
27. Official References
28. Next Steps

Software releases are the process of converting validated source code into versioned artifacts that users can install and reproduce.

EveryO's release process should protect:

• Mathematical correctness.
• Public API compatibility.
• Package integrity.
• CPU-only functionality.
• Optional backend isolation.
• Security.
• Documentation accuracy.
• Reproducibility.

A successful release should provide:

1. An approved version number.
2. A reviewed source revision.
3. Passing required checks.
4. Valid Python distribution artifacts.
5. Accurate release notes.
6. A traceable Git reference.
7. Verified installation instructions.

The project maintainer has final release approval authority.

Contributors may prepare changes, tests, documentation, and release proposals, but contribution does not automatically grant publishing privileges.

EveryO prioritizes correctness, clarity, and reproducibility.

A release must not claim:

• Unsupported hardware acceleration.
• Unverified numerical accuracy.
• Unimplemented features.
• Unmeasured performance improvements.
• Unsupported platform compatibility.

EveryO currently declares an alpha development classifier.

Users should expect that some APIs may change as the framework evolves.

Alpha status does not remove the need for correctness, security, or transparent documentation.

The following configuration is verified from the repository's pyproject.toml.

[build-system]
requires = ["setuptools>=68", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "everyo"
version = "0.2.0"
requires-python = ">=3.9"

The repository declares:

tensorflow
yaml
onnx
dev
cuda

[project.scripts]
everyo = "everyo.cli.main:main"

The inspected changelog records:

0.2.0 — 2026-09-19

It also contains an Unreleased section.

The package metadata and changelog establish the project's declared version; they do not independently confirm publication to PyPI.

EveryO's changelog states that the project follows Semantic Versioning.

MAJOR.MINOR.PATCH

Example:

0.2.0

Under Semantic Versioning, the public API may change during 0.y.z initial development.

EveryO should still document compatibility impacts and provide migration guidance for significant changes.

These are examples, not approved future release numbers.

Python packaging supports pre-release identifiers such as:

0.3.0a1
0.3.0b1
0.3.0rc1

Use pre-releases when testing a candidate before general release.

Typically contains:

• Bug fixes.
• Security fixes.
• Documentation corrections.
• Compatible maintenance improvements.

Typically contains:

• New tensor operations.
• New neural network layers.
• New training functionality.
• New interoperability capabilities.
• Approved API extensions.

Typically represents a significant compatibility milestone.

Used to validate a candidate before broader adoption.

May be needed for:

• Critical security vulnerabilities.
• Severe correctness regressions.
• Broken package installation.
• Data-loss defects.

Emergency releases still require proportionate validation and maintainer approval.

          Release Proposal
                 |
                 v
          Scope Definition
                 |
                 v
        Maintainer Approval
                 |
                 v
         Version Preparation
                 |
                 v
        Changelog Finalization
                 |
                 v
       Tests and Quality Checks
                 |
                 v
        Security and API Review
                 |
                 v
          Package Building
                 |
                 v
        Artifact Verification
                 |
                 v
       Clean Installation Test
                 |
                 v
          Release Approval
                 |
                 v
       Package Publication
                 |
                 v
       Git Tag / GitHub Release
                 |
                 v
        Post-Release Validation

This workflow is a recommended operational procedure.

Before preparing a release, define its scope.

A proposal should identify:

• Candidate version.
• Intended changes.
• Relevant issues and pull requests.
• Compatibility impacts.
• Known risks.
• Test requirements.
• Documentation work.
• Release owner.

For larger releases, maintainers may establish a feature freeze.

During a freeze, changes should generally be limited to:

• Bug fixes.
• Security corrections.
• Test stabilization.
• Documentation.
• Release-blocking fixes.

Only the maintainer can approve the final release scope under current governance.

A roadmap item does not guarantee a release date.

• Approved features implemented.
• Release-blocking bugs addressed.
• Public APIs reviewed.
• Known limitations documented.

• CPU tests pass.
• Ruff lint passes.
• Formatting passes.
• Relevant integration tests pass.
• Package build succeeds.

• Changelog finalized.
• Installation instructions accurate.
• Examples verified.
• Compatibility changes documented.

• No unresolved release-blocking security issue.
• No secrets in artifacts.
• Dependencies reviewed.
• Package contents inspected.

EveryO currently declares its version in pyproject.toml.

grep -n '^version =' pyproject.toml

On Windows, inspect the file directly or use Python:

import tomllib

with open("pyproject.toml", "rb") as file:
    metadata = tomllib.load(file)

print(metadata["project"]["version"])

tomllib is available in Python 3.11 and later. On Python 3.9–3.10, use a compatible TOML reader or inspect the file manually.

Example only:

[project]
version = "0.2.1"

Do not change the version until the proposed release number is approved.

Check:

• Package metadata.
• Changelog.
• Documentation badges.
• Release notes.
• Git tag.

The current package metadata is the authoritative declared package version.

If the project later introduces dynamic versioning, document the new source of truth before adopting it.

EveryO maintains:

CHANGELOG.md

The changelog follows Keep a Changelog and Semantic Versioning.

During development:

## [Unreleased]

### Added

- New functionality.

### Changed

- Updated existing behavior.

### Fixed

- Corrected defects.

At release time, move applicable entries from Unreleased into a versioned section.

Example:

## [Unreleased]

## [0.2.1] - YYYY-MM-DD

### Fixed

- Corrected a verified regression.

Replace the placeholder date with the actual approved release date.

Each entry should explain:

• What changed.
• Why it matters.
• Relevant limitations.
• Compatibility impacts where applicable.

Avoid unsupported marketing claims.

python -m pytest -q

ruff check .

ruff format --check .

python -m compileall -q everyo

python -m pytest \
  --cov=everyo \
  --cov-report=term-missing

For tensor and autograd changes:

• Forward correctness.
• Backward correctness.
• Finite-difference gradients.
• Broadcasting.
• Numerical edge cases.

Record the commands executed and their results.

Do not mark checks as passed unless they actually completed successfully.

The project declares Python 3.9 or newer.

The inspected package classifiers explicitly list Python 3.9 through 3.12.

Newer versions should be tested before claiming verified compatibility.

Validate relevant behavior on:

• Linux.
• Windows.
• macOS.

The core package must remain usable without:

• CUDA.
• TensorFlow.
• GPU hardware.
• API keys.

Where applicable, validate:

• TensorFlow interoperability.
• ONNX export.
• ONNX Runtime execution.
• CUDA functionality.

Do not claim CUDA validation based solely on CPU fallback tests.

Before publishing:

• Check for exposed credentials.
• Inspect newly added dependencies.
• Review serialization changes.
• Verify untrusted inputs are handled safely.
• Investigate known security advisories.

Core dependencies currently include:

numpy>=1.22
matplotlib>=3.5

Optional extras should remain optional.

Inspect source distributions and wheels before uploading.

Avoid including:

• .env files.
• API keys.
• Private certificates.
• Local credentials.
• Internal datasets.
• Unnecessary build artifacts.

Follow:

SECURITY.md

Security-sensitive details should not be disclosed publicly before coordinated disclosure.

EveryO uses setuptools.

python -m pip install --upgrade build twine

Remove old build outputs carefully.

Linux/macOS:

rm -rf build dist

Windows PowerShell:

Remove-Item build, dist -Recurse -Force -ErrorAction SilentlyContinue

python -m build

A successful build should produce artifacts similar to:

dist/
├── everyo-<version>-py3-none-any.whl
└── everyo-<version>.tar.gz

Exact filenames depend on the approved version and build configuration.

The build should complete without errors.

Warnings should be reviewed rather than automatically ignored.

python -m twine check dist/*

python -c "from pathlib import Path; print('\n'.join(str(p) for p in Path('dist').iterdir()))"

from pathlib import Path
from zipfile import ZipFile

for wheel in Path("dist").glob("*.whl"):
    with ZipFile(wheel) as archive:
        for name in archive.namelist():
            print(name)

import hashlib
from pathlib import Path

for path in Path("dist").iterdir():
    if not path.is_file():
        continue

    digest = hashlib.sha256(path.read_bytes()).hexdigest()

    print(path.name, digest)

For very large files, stream bytes in chunks instead of reading the entire artifact into memory.

• Correct package name.
• Correct version.
• Valid metadata.
• Expected source files.
• No sensitive content.
• Successful installation.
• Expected runtime behavior.

A release candidate should be installed in a clean environment.

python -m venv .release-venv

Linux/macOS:

source .release-venv/bin/activate

Windows PowerShell:

.release-venv\Scripts\Activate.ps1

python -m pip install dist/everyo-<version>-py3-none-any.whl

Replace <version> with the actual wheel filename.

python -c "import everyo; print('EveryO import successful')"

python -m everyo info

import numpy as np
import everyo as eo

x = eo.tensor(
    [2.0],
    requires_grad=True,
)

y = x * x
y.backward()

np.testing.assert_allclose(
    x.grad,
    [4.0],
)

print("Release smoke test passed")

The expected success message is illustrative; run the test to establish actual results.

TestPyPI provides a separate index for testing Python package publication.

TestPyPI publishing requires appropriate credentials or a configured trusted-publishing workflow.

Do not place credentials in source files.

For a project and version not already present on TestPyPI:

python -m twine upload \
  --repository testpypi \
  dist/*

Example:

python -m pip install \
  --index-url https://test.pypi.org/simple/ \
  --extra-index-url https://pypi.org/simple/ \
  everyo==<version>

Replace <version> with the uploaded version.

Check:

• Package metadata.
• Dependency resolution.
• Installation.
• Imports.
• CLI behavior.
• Representative tensor operations.

TestPyPI publication is recommended as a validation step, not an existing EveryO requirement verified from repository automation.

Production publication requires explicit maintainer authorization.

• Version approved.
• Source revision approved.
• Changelog finalized.
• Tests validated.
• Artifacts inspected.
• Credentials or trusted publishing configured.

For an authorized maintainer:

python -m twine upload dist/*

For future automation, prefer PyPI Trusted Publishing using OpenID Connect where supported.

This avoids storing long-lived PyPI API tokens in GitHub repository secrets.

After publishing, verify the actual project page and distribution files on PyPI.

Do not assume that a successful local build means the package is publicly available.

PyPI generally does not allow replacing an uploaded distribution file with the same filename.

Corrections normally require a new version.

Git tags identify specific source revisions.

git status

git log -1 --oneline

Example:

git tag -a v0.2.1 -m "EveryO v0.2.1"

Use only an approved version and verified release commit.

git push origin v0.2.1

Open:

EveryO Releases

Create a release associated with the approved tag.

Where appropriate, attach:

• Source distribution.
• Wheel.
• Checksums.
• Release notes.

Agree on the publication sequence before creating the final tag or uploading artifacts.

A release tag must point to the exact source revision used to build the published package.

Release notes explain changes to users.

# EveryO vX.Y.Z

Release date: YYYY-MM-DD

## Overview

Summarize the release.

## Added

- New functionality.

## Changed

- Behavior changes.

## Fixed

- Corrected defects.

## Compatibility

- Supported Python versions.
- API migration notes.

## Known Limitations

- Relevant limitations.

## Installation

```bash
python -m pip install everyo==X.Y.Z

• Changelog
• Git tag
• Relevant pull requests

## 20.2 Release Note Requirements

- Accurate claims.
- No fabricated benchmarks.
- Clear compatibility information.
- Honest limitations.
- Links to relevant source history.

---

# 21. Release Automation

Automated releases can reduce manual errors.

## 21.1 Current Verification

The inspected repository contains package metadata and governance documentation.

However, conventional publishing workflows at:

```text id="20u9ho"
.github/workflows/publish.yml
.github/workflows/release.yml

were not found during this inspection.

This does not rule out differently named workflows.

Git Tag
   |
   v
Validate Version
   |
   v
Run Tests
   |
   v
Run Lint and Formatting
   |
   v
Build Wheel and sdist
   |
   v
Validate Artifacts
   |
   v
Publish via Trusted Publishing
   |
   v
Create GitHub Release
   |
   v
Verify Published Package

A future release workflow should use:

• Restricted publishing permissions.
• Protected release environments.
• Explicit maintainer approval.
• Trusted Publishing.
• Minimal GitHub Actions permissions.
• Artifact provenance where supported.

Release automation should be implemented through a reviewed pull request and approved by the maintainer.

A published package may contain a critical defect.

• Incorrect numerical results.
• Broken installation.
• Security vulnerability.
• Package corruption.
• Severe regression.
• Incompatible dependencies.

1. Confirm the problem.
2. Assess severity.
3. Stop or postpone further publication if necessary.
4. Notify the maintainer.
5. Investigate the affected version.
6. Prepare a corrected version.
7. Validate the correction.
8. Publish an advisory or release note as appropriate.

An uploaded package cannot normally be replaced in place.

A corrected release generally needs a new version.

PyPI supports yanking releases to discourage new installations while preserving access for certain exact-version requirements.

Yanking is not equivalent to deleting or replacing a release.

Avoid silently moving published release tags.

Preserve traceability between source code and distributed artifacts.

Release work continues after publication.

Test installation from the actual published package index.

Run representative examples:

• Tensor operations.
• Automatic differentiation.
• Neural network forward pass.
• Model training.
• Serialization.
• CLI commands.

Confirm:

• Release notes are accessible.
• Installation commands are correct.
• Version badges are accurate.
• Changelog links work.

Review:

• New bug reports.
• Installation failures.
• Compatibility regressions.
• Security reports.
• Documentation issues.

When necessary, prepare a patch release using the same review and validation principles.

The maintainer owns final release decisions.

• Approve scope.
• Approve version.
• Review changelog.
• Confirm required validation.
• Review security considerations.
• Approve artifacts.

• Confirm the release commit.
• Verify publication authorization.
• Approve package distribution.
• Confirm Git tags and release notes.

• Verify published artifacts.
• Monitor regressions.
• Coordinate security responses.
• Plan follow-up fixes.

Publishing permissions may be delegated under project governance, but contributors do not automatically receive release access.

• Release scope defined.
• Version proposed.
• Maintainer approval obtained.
• Relevant issues and PRs reviewed.

• Approved changes merged.
• Version metadata updated.
• Changelog finalized.
• Documentation updated.
• Working tree clean.

• CPU tests pass.
• Ruff lint passes.
• Ruff formatting passes.
• Compilation checks pass.
• Relevant optional backend tests reviewed.
• Numerical correctness verified.

• No credentials in artifacts.
• Dependencies reviewed.
• No unresolved release-blocking vulnerabilities.
• Distribution contents inspected.

• Wheel built.
• Source distribution built.
• twine check passes.
• Clean installation succeeds.
• Smoke tests pass.
• Artifact hashes recorded where appropriate.

• Final maintainer authorization obtained.
• Package index and project ownership verified.
• Approved artifacts published.
• Git tag points to release source.
• GitHub release created.
• Release notes published.

• Published package installation verified.
• Documentation links checked.
• Known issues recorded.
• Follow-up monitoring assigned.

python -m pip install build

python -m build

python -m twine check dist/*

Continue with the remaining EveryO project documentation.

Wiki links become active after their corresponding pages are created.