Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document TypeScript version lifetime and EOL #49088

Closed
indrora opened this issue May 12, 2022 · 11 comments · Fixed by #55962
Closed

Document TypeScript version lifetime and EOL #49088

indrora opened this issue May 12, 2022 · 11 comments · Fixed by #55962
Assignees
Labels
Docs The issue relates to how you learn TypeScript

Comments

@indrora
Copy link

indrora commented May 12, 2022

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.

@andrewbranch andrewbranch added the Docs The issue relates to how you learn TypeScript label May 24, 2022
@indrora
Copy link
Author

indrora commented Jun 28, 2022

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

@RyanCavanaugh
Copy link
Member

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
Copy link

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
Copy link

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

@indrora
Copy link
Author

indrora commented Jun 7, 2023

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
Copy link

ben-zen commented Jun 7, 2023

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
Copy link
Author

indrora commented Sep 9, 2023

Any progress on this?

@PoulChapman
Copy link
Member

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

@broofa
Copy link

broofa commented Nov 11, 2024

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
Copy link
Member

jakebailey commented Nov 11, 2024

"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
Copy link

broofa commented Nov 11, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Docs The issue relates to how you learn TypeScript
Projects
None yet
10 participants