Long Term Support Releases

What is a Tyk Long Term Support (LTS) Release?

A Tyk LTS release is usually aimed at customers who want predictability and stability. It means that throughout the lifetime of the release, there will be a commitment to update, fix and maintain the elements that are part of the release. Our LTS releases are scheduled for Q1 release annually.

How do we support LTS releases?

An LTS release at Tyk is left on production for 3 months in Hypercare - a period immediately after a release where an elevated period of support is available, patches are run based on need and criticality, and single fix patching is done whenever needed. During this period, the release is carefully monitored and anything that needs fixing is fixed then and there to ensure stability.

During the Hypercare period, measures are taken to stabilise the release, and breaking changes are released. All this is done while also aiming for backward compatibility.

After the Hypercare 3 month period, this release is labelled as a recommended release to customers. This is followed by full support for 12 months. This means that the release will be on full support for 15 months.

Note: Minor releases are not a part of the LTS but are fully supported until the next minor release is live.

After 12 months, there is a new LTS release, and the previous version remains in full support for a further 3 months before it moves into extended support.

If you are on an LTS release (RX.0), you can directly put any minor release on top of that (RX.1, RX.2, etc) instead of installing the previous version of the minor release.

LTS release timetable

What Happens To Our Patches When We Release A LTS Release?

Our approach is quite simple. When we release a new long term support (LTS) release (usually March each year), we like to give it until the end of May to breathe, and then we make it our recommended version.

So, from March until May we continue to patch both the old LTS branch, and the new LTS branch. And then, in June, we patch the new LTS version only, and the old LTS version moves into extended support, which is essentially critical fix only.

Here’s an illustration:

Our current LTS release is release 4. Our new LTS release 5, is due out in March.

In April and May , we will release a patch for our r4 LTS release (4.0.13 and 4.0.14) and for our new r5 LTS release (5.0.1 and 5.0.2).

In June, we release our next major release for release 5 (5.1) so at this stage we will patch R5 and R5.1 (5.0.3 and 5.1.1).

Also in June we will  end patching of R4 LTS each month and this will move into extended support, which is severity 1 fixes and critical security patching.

Enterprise Portal

We strive to avoid any long term support arrangements for our enterprise portal. We run a regular 6 week release cadence which delivers new capability, extension of existing capability, and bug fix. Our policy is that we aim to avoid any breaking changes, so in effect the entire enterprise portal is supported. Here we'd increment our version as a minor version - 1.3.0, 1.4.0, 1.5.0 etc.

Occasionally, we may see a need to issue a critical fix if there is a systems down or a critical security defect. Here we would release this as soon as is physically possible, and the semantic versioning would reflect a patch (1.3.1, 1.4.1 etc).

The only exception to this policy is if we ever need to release a breaking change. This would mean that we have to release a new major version (i.e. releasing version 2.0). In this exceptional circumstance we would support both the old major version and the new one concurrently for six months - please note that the old version only gets supported in terms of critical fixes, not new functionality. After the six months is up, the previous major version falls out of support.

Other Components

Minor updates to Tyk Pump, Tyk Identity Broker (TIB), MDCB, and Operator are deployable quickly with low risk and no breaking changes, Tyk will support the latest major.minor version (e.g. Pump 1.7) until the next major.minor version (1.8) is released. Then we’d support that version.

To help assure backward compatibility we ensure that each version of Pump and other components we release works with the gateway and dashboard versions which are under LTS (long-term support) at that time. For example, we’d ensure Pump v1.7 is compatible with release v4 of Tyk gateway and Tyk Dashboard, and this increments with the LTS model.

Following semver convention, if we need to patch a minor Pump version , we would number that as a patch version (e.g. 1.7.1).

What is Hypercare?

Hypercare is a period immediately after a release where an elevated period of support is available. We run patches based on need and criticality, and single fix patching can be done if the severity and impact of a bug denotes that a fix is critical.

What is Extended Support?

In the extended support period Tyk will continue to patch any production critical patches and security issues, we will not add new features to the platform during this period.

How do we support minor releases?

We only patch our minor releases (4.1. 4.2, 4.3, etc) until the next minor is out.

Example for release 4

• Our next LTS patch release will be 4.0.3, and a minor release (4.1) will have all of the 4.0.3 patches
• The following LTS patch release will be 4.0.4 and our minor release 4.1 will be patched, becoming 4.1.1
• The following LTS patch will be 4.0.5 and our minor release 4.1.1 will be patched, becoming 4.1.2
• The following LTS patch will be 4.0.6 and a new minor release (4.2) will have all of the 4.0.6 patches
• At this point we stop supporting minor release 4.1 and only patch 4.2
• This schedule is repeated until our next LTS release