Hype5 Docs

Hype5 Theater 0.7.0 · Beta — by invitation

Compatibility and deprecation

Hype5 Theater and Hype5 Stage are pre-release. This page states the rules that apply today, as they are written in the products' code and documentation, and what is not yet decided.

On this page

Status today

  • Hype5 Theater is at 0.7.0 (Beta — by invitation) and Hype5 Stage at 1.0.2 (Pre-release). Theater 0.7.0 is the first version with its own number after the 0.6.17 pre-release builds.
  • Theater 0.7.0 defines the presentation API 1.0 (HYPE5_THEATER_API = '1.0'): the services, view shapes, hooks and constants marked Stable on Presentation services, including the visibility service Data\Visibility. A minor number adds to the contract; a major number changes or removes something. The classification is to be confirmed at version 1.0 of Hype5 Theater. The rest of the documented public surface has not been classified yet.
  • A formal deprecation schedule (how long a deprecated interface keeps working) has not yet been published. Until it is, treat every upgrade as something to test.

What each class promises

Class Promise
Stable Documented behaviour that themes and add-ons may rely on. Changes go through deprecation rather than silent removal.
Public Documented for third-party use (shortcodes, blocks, public REST routes, hooks, template keys, labels, URL parameters, the add-on interface) but not yet formally classified. Changes are recorded in the changelog; a deprecation promise has not been made for them yet.
Provisional Belongs to the Hype5 app and is not yet classified as stable (for example the app's save actions). It works but may change.
Internal An implementation detail. May change in any release. Not supported for third-party use.

Internal by definition: the /hype5-theater/v1/app/* REST routes; storage formats of post meta, term meta, options and custom tables; _internal/ templates and the integration shells single.php, single-block.php and collection-page.php; services marked Internal on Presentation services.

Template versions

Each public template declares @version X.Y.Z describing its data contract, not its styling.

  • When the plugin raises a template's version, an override with a lower version is reported in System Status as Review recommended (outdated).
  • A major change (for example 1.x → 2.0.0) means the view data changed incompatibly. Hype5 Stage, for example, falls back to the plugin's template automatically in that case.
  • A minor change (for example 1.0.0 → 1.1.0) adds to the contract; existing overrides keep working but should be reviewed. Phase 5K raised production.performance to 1.1.0, adding the withheld state.

See Template overrides → Version headers.

Database schema

The schema is versioned (hype5t_db_version, currently 5) and migrated by the plugin. Migrations are idempotent, keep existing data and are marked complete only when every step succeeded. Upgrading or removing the plugin never deletes user content.

Hype5 Stage and Hype5 Theater

  • Stage declares the Theater version it is built against (0.6.17 with the Phase 5K presentation contract for Stage 1.0.2) and switches its enhancements off without it. Because several pre-release builds share the number 0.6.17, Stage 1.0.2 checks for the plugin's visibility service rather than relying on the number; Theater 0.7.0 passes this check.
  • Theater 0.7.0's release metadata names Hype5 Stage 1.0.2 as the minimum and tested Stage version (presentation API 1.0). Themes can check HYPE5_THEATER_API instead of the plugin version.
  • Stage guards every call to the plugin, so an incompatible plugin change removes the affected home-page section rather than breaking the site.
  • The compatibility matrix lists which versions have been tested together.

How changes are announced

Changes to public interfaces are recorded in the changelogs. Each documentation page names the product version it describes, and Documentation versions explains how documentation for older versions is kept.

Recommendations

  • Use stable interfaces only, and wrap anything else.
  • Pin and test: try new versions on a staging copy of your site before updating production.
  • Check System Status for outdated overrides after every update.