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 is a worked example.

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.

Pump

As updates to Tyk Pump are deployable quickly with low risk and no breaking changes, Tyk will support the latest major version (I.e Pump 1.7) until the next major version (1.8) is released . Then we'd support that version.

To help assure backward compatibility we ensure that the each version of Pump we release works with the gateway and dashboard versions which is under long term support at that time. For example, we'd ensure Pump 1.7 is compatible with release 4 of our gateway and dashboard, and this increments with the long term support model.

If we need to patch a major Pump version , we would number that as a minor version (1.7.1).

Other Components

Our TIB, and MDCB components will not be a part of our long term support policy yet, they are compatible with all supported versions of Tyk. We will continue to support all versions of these components, and will offer advice to clients on when to upgrade if necessary. 

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