Release Notes

The maintained Changelog records the current component baseline and version-scoped historical material. Blog posts explain context, but version-sensitive upgrade decisions must also be captured in compatibility, migration, and verification pages.

Current Entry Points

• TeaQL 1.0.0 Release Notes
• Rust v0.7.0 Release
• Java Runtime Modular Refactor
• Spring Boot 4.1 Support
• Why TeaQL Rust Removed SQLx

These posts were written at different points in the product's evolution. Old dependency names, versions, or commands may no longer match the current generator. Confirm operational details through maintained reference pages and the installed client.

Required Release-Note Structure

Every new release note should include:

1. Release date and component versions.
2. Supported or tested compatibility baseline.
3. Added capabilities.
4. Changed behavior.
5. Deprecated and removed surfaces.
6. Generated API impact.
7. Configuration and environment changes.
8. Provider, schema, and transaction impact.
9. Security or audit impact.
10. Upgrade and rollback links.
11. Verification commands and known limitations.
12. Lifecycle impact: unchanged, newly supported, deprecated, or EOL. A support label also requires the dates and scope defined by Support Lifecycle.

Publication Workflow

For each release:

1. Publish the narrative release note.
2. Update the Compatibility Matrix.
3. Add version-specific Migration Notes for breaking behavior.
4. Verify the Java and/or Rust golden path.
5. Update command, configuration, environment, and diagnostic references.
6. Record generated diff and build/test evidence.

Changelog Status

A maintained version index now exists, but upstream component history is still incomplete: current artifact versions do not all have aligned immutable tags, publication dates, and release notes. The Changelog therefore distinguishes a verification snapshot from a release date and records unknown history without inventing it.