Document TypeScript version lifetime and EOL

[indrora]

Bug Report: Documentation.

There is no documented lifecycle time for a particular version of TypeScript.

Python, Go, and Node all have defined lifetimes for releases.

🔎 Search Terms

• Typescript End of life
• Typescript version support matrix
• typescript version support history
• how long is a version of typescript supported for

🙁 Actual behavior

No documentation exists.

🙂 Expected behavior

Having a list or guideline of how long versions of the TypeScript library/compiler/etc are supported for so that I can make informed decisions on security and SDLC inquiries.

[indrora]

With another release of TypeScript coming around the corner, I'm curious if there's been some official thought on this?

[RyanCavanaugh]

To my knowledge, we don't have an official policy beyond the one implied by the fact that we ship our components in Visual Studio. Security fixes are backported I believe for the last year of releases; non-security fixes are not backported. If there's a more concrete definition of "support" provided, or a specific hypothetical you had in mind, I can speak to that specifically.

[marcwrobel]

There is also this paragraph in the documentation on https://github.com/microsoft/TypeScript/wiki/TypeScript%27s-Release-Process#what-gets-done-for-patch-releases :

Patch releases are periodically pushed out for any of the following: ... These fixes are typically weighed against the cost (how hard it would be for the team to retroactively apply/release a change), the risk (how much code is changed, how understandable is the fix), as well as how feasible it would be to wait for the next version.

[postmeback]

If the concept of version lifetime and EOL is irrelevant with TypeScript, then we can close this issue.

[indrora]

If that's the case, then are bugfixes going to be backported and language features backported to older versions of the typescript compiler?

That is the expectation of a "supported" version of such a piece of software.

[ben-zen]

Jumping in as I've been bit by the unclear lifecycle for TypeScript before: this is inconsistent with other Microsoft languages and software distributions. .net (core and otherwise) has a very clear lifecycle document which sets expectations well for users.

From a quick look through the release history, it doesn't appear to me that there are many updates made to prior major versions once a new major version (or even generally minor version) has hit stable; I had to search all the way back to June 2021, where 3.9, 4.0, and 4.1 got patches for Node 16, when 4.3 was the current stable version.

That dotnet policy document states, "Every Microsoft product has a lifecycle. The lifecycle begins when a product is released and ends when it's no longer supported." Does typescript abide by the Modern Policy Lifecycle? If not, why not?

[indrora]

Any progress on this?

[PoulChapman]

We've now published a clarification of support at https://github.com/microsoft/TypeScript/blob/main/SUPPORT.md, and have closed this issue.

[broofa]

Can we reopen this, please?

I'm one of the maintainers of the uuid module. Our platform support policy for node has been "uuid supports all current node LTS versions, plus one prior release". This works well for us because it lets us plan how / when code and platforms can be deprecated.
Having recently added TS support, it's quickly become apparent that we should have a similar policy for TypeScript.

While trying to answer the question, "What is the Typescript release and support lifecycle?", I've landed here.

The SUPPORT.md page that @PoulChapman links to is disappointingly unhelpful. It provides a link to MSFT's generic Modern Support Policy, where searching for "typescript" returns zero results, and little else.

Regarding @RyanCavanaugh's comment about TS being implicitely tied to VS's release lifecycle, that's maybe a bit more helpful, but I see no mention of TS version on the VS 2022 release page. I suppose I could go google-golfing a bit further to see what versions of TS ship with each of those releases, but that's more work than I'm willing to put into this question.

It'd be great if there were a graphic for TS like this one that showed up at the top of my Google results when seeking an answer... except, you know, from an official source with some credibility. See also the previously mentioned Node.js Releases page for other inspiration.

Cc: @DanielRosenwasser

[jakebailey]

"Support" is a hard term to define; do you mean fixes to behavior? Crash fixes? Security fixes? Stability guarantees?

We release quarterly. Only the previous version is supported for bugfixes only (mainly bad regressions, crashes). We may patch older versions for security fixes (very very rare, there really isn't much that can be CVE'd such that that's required).

If you use this pattern to determine your support window, you'd only be supporting one TS version. That doesn't seem right; all we're saying is that we aren't going to go futz with the behavior of old TS releases, which would imply more stability if anything.

Definitely Typed maintains compatibility with the last two years of TS releases (https://github.com/DefinitelyTyped/DefinitelyTyped#support-window). This is also the general window typescript-eslint uses. I think that for a library maintainer, that window is a much more reasonable guideline to use than TypeScript's own support policy for the compiler itself.

Many projects determine that to be too large of a range too and support less.

You can also use projects like tstyche to test your code against multiple versions of TS, or some other alternative.

[broofa]

@jakebailey Thanks for this update. The "two years" cutoff concept is helpful. It sounds like we should just take a similar stance then.