Support and Release Policy

InterDiode follows a rolling release model for self-hosted/on-premises deployments.

This means customers with an active InterDiode subscription receive ongoing product updates, bug fixes, security updates, and access to support. Rather than publishing a large set of long-lived public maintenance branches with separate end-of-life dates for each version, InterDiode is delivered as a continuously updated product.

At a glance

  • Release model: Rolling release.
  • Who receives updates: InterDiode images are freely downloadable but only .
  • What is included: Ongoing feature updates, bug fixes, security updates, and Enterprise support during the active subscription period.
  • Major version support window: A major version remains the current supported line until the next major version becomes the recommended upgrade path.
  • Upgrade expectation: Customers should stay within the recommended upgrade window to remain current with the latest fixes and security improvements.
  • Security releases: Important security fixes may be released outside the regular cadence when needed.

How releases work

InterDiode is released on a predictable cadence so teams can plan upgrades for production environments. In addition to scheduled releases, we may publish out-of-band updates when necessary to address important security issues or urgent fixes.

Major versions do not follow a fixed three-month schedule. Release timing varies by release readiness and current planning, and each major version remains the current supported line until the next major version becomes the recommended path.

Because InterDiode currently follows a rolling release model, the main support question is not whether an older feature branch remains publicly maintained for an extended period. Instead, the goal is to keep supported customer deployments on an advised upgrade path with current fixes and security updates.

Production upgrade guidance

For production environments, we recommend:

  1. validating new releases in a staging environment before production rollout
  2. following the recommended upgrade path for your deployed version
  3. staying reasonably current rather than delaying upgrades for long periods
  4. contacting us early if your environment has operating system, database, or change-management constraints

This approach helps reduce operational risk while ensuring access to the latest security and reliability improvements.

Versioning and lifecycle

InterDiode does not currently publish a public lifecycle matrix with separate end-of-life dates for every version in the style of products that maintain many public long-lived release branches. Instead, a major version remains current until the next major version is released and becomes the recommended upgrade path.

Instead, the public policy is based on the rolling release model and the active subscription period. If your procurement or operations process requires a more conservative rollout plan, please contact us and we can discuss the most suitable release strategy for your environment.

FAQ

Does InterDiode have fixed end-of-life dates for each version?

InterDiode is currently delivered as a rolling release rather than a broad set of public long-lived maintenance branches with separate fixed end-of-life dates for each version. In general, a major version remains the current supported line until the next major version is released and becomes the recommended upgrade path.

How does InterDiode differ from products that publish per-version EOL tables?

Some self-hosted enterprise products publish a separate end-of-life date for each feature release and maintain multiple long-lived public release branches in parallel.

InterDiode currently follows a rolling release model instead. Customers with an active subscription receive ongoing product updates, bug fixes, security updates, and support, and major version timing is communicated through the published recent and planned release schedule.

This model is designed for teams that prefer a continuously updated self-hosted platform and a predictable upgrade path, rather than a large matrix of long-lived public maintenance branches. For organizations that require a more conservative rollout approach, we recommend validating releases in staging first and contacting us to discuss the most suitable upgrade strategy for their environment.

How should we plan upgrades for an on-premises deployment?

We recommend testing releases in a staging environment first, then upgrading production within the advised release window so your deployment stays current with the latest fixes and security improvements.