TypeScript (breaking) upgrades only available on major releases

[Soremwar]

Things like #8690 shouldn't happen with every minor release like 1.6 IMO

Maybe after 2.0 SEMVER could be enforced a little more aggresively?
Maybe adopt another method of versioning?

However a thing that I see as necessary is a flag required when doing deno upgrade so users understand a breaking change is included in the latest release

[crowlKats]

I do see your point, but that would mean we'd upgrade TS once a year, whereas TS gets a minor around every 3 months, making us extremely out of the loop and giving a big reason for people not to use Deno but rather node imo

[kitsonk]

We will continue to upgrade TypeScript close to the release of TypeScript.

[Soremwar]

@kitsonk Could the second proposal (flag required when updating to breaking) be considered then?

[kitsonk]

TypeScript has a policy that have minor release of TypeScript can have breaking changes. It becomes really difficult to attest to if a change is a breaking change. Also, deno upgrade is only one way of upgrading Deno.

We need to be more clear in our release notes when we upgrade versions of TypeScript though, and ensure that people understand any changes to TypeScript.

In my opinion there are sufficient mitigation strategies though to deal with "breaking" code, which we need to document better as well (see #8139) but one can currently:

• Use --no-check to avoid any type checking errors like the mentioned issue.
• Use @ts-ignore for code under the control of the user until the code can be updated.
• Use import maps to "replace" any code that isn't under the control of the user.

I will make sure examples of each of those are included in the docs.