Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions about/release-policy.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
---
title: "Release & Support Policies"
description: "How iroh versions are released, how long they're supported, and what wire-protocol compatibility you can rely on."
---

This page describes how iroh is versioned, what compatibility guarantees we make between versions, and how long each release is supported.

## Release Types

| Type | Description | Cycle | Example |
|------|-------------|-------|---------|
| Major | New features, breaking changes | ≥6 months | `1.0.0` |
| Minor | Incremental features, improvements | ≥4 weeks | `1.2.0` |
| Patch | Bug fixes, security updates | As needed | `1.2.3` |
| Release candidate | An early preview of an upcoming release, with higher confidence that the API is approaching stability | As needed | `1.0-rc` |
| Canary | An early preview of an upcoming release with an unstable API | As needed | `0.97` |
| Experimental | Fork or branch for a particular use case or prototype | As needed | `branch-name` |

## Wire Protocol Compatibility

The wire protocol must remain backward-compatible with the *non-deprecated* parts of the *previous* major version series. It may break compatibility with versions older than the last.

- `2.x`'s wire protocol must be backward-compatible with `1.x`
- `3.x`'s wire protocol must be backward-compatible with `2.x`
- `3.x`'s wire protocol *may* be backward-incompatible with `1.x`

The wire protocol must also remain compatible across minor versions within the same major series. For example, `2.x` must connect with any `2.1` through `2.x`.

| Version | Compatible with |
|---------|-----------------|
| 1.x | 1.0 ≤ 2.0.x |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be at least 1.x and 2.0.y as these are no the same variables

| 2.x | 2.0 ≤ 3.0.x |
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be 1.0 <= 2.x.y? Or do you explicitly want to be ale to deprecate things in minor releases and then drop compatibility with that in the next major release? That seems a little aggressive to me, but also not entirely unreasonable.


### Recommendations

- Before deploying the next major version (e.g. `v2.0`), ensure all devices have been updated to the latest previous major (e.g. `v1.x`).
- Before deploying the next minor version (e.g. `v2.1`), ensure all devices have been updated to the latest major (e.g. `v2.0`).
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried this might force us to do a lot of 2.0.y releases in parallel with 2.1.y releases.

Copy link
Copy Markdown
Contributor Author

@okdistribute okdistribute May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, there's lots of ways to do this. We don't have to do it this way, open to other ideas

The alternative is then we have to make sure that all 2.X releases are compatible with 1.x releases.

If we force folks to upgrade to 2.0 first, that reduces our matrix of testing for the later 2.x releases.


## Support Policy

**Full Support**: The version is fully supported. Number 0 provides timely bug fixes, security patches, and ongoing maintenance. Expect active development and prompt response to issues.

**Extended Support**: A paid support tier for versions that have exited Full Support. Under Extended Support, Number 0 provides critical bug fixes and security patches for a defined period. It includes service level agreements (SLAs) covering response and resolution times for critical issues, including security vulnerabilities and high-severity defects.

**Maintenance Mode**: The version is stable and no longer under active development. Only critical bug fixes or security patches may be provided, solely at Number 0's discretion. No new features or enhancements will be introduced.

**End of Life (EOL)**: The version is no longer supported. No bug fixes, security updates, or maintenance will be provided. Continued use is at the customer's own risk, and upgrading is strongly recommended.

| Release | Full Support | Maintenance Mode | Extended Support |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to frame this a bit differently, we will provide full support for the latest version, eg 1.5.3 and not 1.0.0 for this time

|---------|--------------|------------------|-------------------|
| Major | 1 year | 1–3 years after release | [Contact us](mailto:support@iroh.computer) |
| Minor | 3 months | 3 months – 1 year after release | [Contact us](mailto:support@iroh.computer) |
| Canary | N/A | N/A | [Contact us](mailto:support@iroh.computer) |
| Experimental | N/A | N/A | N/A |
| Release Candidate | N/A | N/A | N/A |

### Examples

1. If you are using `0.35` in production, `0.35` is a minor version of iroh that is older than 1 year. To get bug fixes, feature backports, or security patches, you need to purchase an Extended Support package.
2. If you find a bug in a version which is older than 3 months, the team may choose to patch the issue in the latest minor release. If you do not want to update to the latest minor and would prefer a backport to your current minor version, you must purchase an Extended Support package to fund the labor of backporting and maintaining a minor version older than 3 months.

For more on support tiers and SLAs, see the [Support page](/iroh-services/support) or [contact us](https://iroh.computer/services/support).

## Public Relay Version Support

Number 0 runs public relays for the **latest major version** of iroh. For relay support for older versions, please [deploy a dedicated relay](https://services.iroh.computer).
1 change: 1 addition & 0 deletions docs.json
Original file line number Diff line number Diff line change
Expand Up @@ -112,6 +112,7 @@
"pages": [
"about/changelog",
"about/roadmap",
"about/release-policy",
"deployment/security-privacy",
"about/faq"
]
Expand Down
4 changes: 4 additions & 0 deletions iroh-services/support.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,7 @@ On the **Pro** and **Enterprise** plans, you can open support tickets by emailin
Guaranteed response times are available on the **Enterprise** plan. Enterprise SLAs ensure your team gets timely responses based on issue severity.

For uptime SLAs or professional services & support inquiries, [read more about enterprise support](https://iroh.computer/services/support) or [book a meeting](https://n0.computer/n0ps/) with our team.

## Release & Support Policies

For details on iroh release types, wire-protocol compatibility, and how long each release is supported, see [Release & Support Policies](/about/release-policy).
Loading