Announcing TypeScript 7.1 Beta
17 comments · 90% upvoted · source · other discussions
comments
[deleted]
Southern-Search2039
Now eslint can migrate to tsgo
vips7L
How are they on a v7 already?
thy_bucket_for_thee
TS doesn't follow semantic versioning. There was a github issue about just this like 8 years ago, it's done because marketing wants to control the release numbers (not a joke).
danielcw189
on which major version would Typescript be, if they followed Semantic Versioning? Still on 1?
it's done because marketing wants to control the release numbers (not a joke)
doesn't most software do this? version number being defined by marketing or messaging?
thy_bucket_for_thee
I guess, but you wind up in situation where minor numbers break things. Granted none of the TS projects I've ever worked on relied on those features, but it happened to people I know several times in their careers:
https://github.com/microsoft/TypeScript/issues/14116#issuecomment-280592571
This is the comment FWIW.
danielcw189
there is another good point in that comment, that I had not considered
Any time we produced the wrong type or emitted the wrong code or failed to issue a correct error, that's a breaking change, and we fix dozens of bugs like that in every release.
I think that is actually correct. But I would guess, that it is not what SemVer intended.
So should SemVer only cover intentional breaking changes, or also breaking changes that happen due to bugs, and fixing them?
So if a bug is discovered in a software, should the Major Version number be increased, when the bug leads to a breaking change?
It should it be raised again, when the bug is fixed?
thy_bucket_for_thee
Honestly don't know and these types of issues are mostly procedural in nature, it doesn't change how we the consumers update libraries with breaking changes (refactoring for compatibility). If a library breaks our projects we either rollback or try to refactor it.
SemVer always felt like a quick check for us to know whether something is worth investigating or not. Like if v8 breaks our product and the team is busy with other things at the moment, we aren't going to upgrade to the latest version. Without SemVer we'd find out immediately in our CI pipeline, not as efficient but the remedies are still the same.
I'm unaware of any tooling that automatically handles SemVer based on commit messages, guessing it exists because with conventional commits it's not hard to "guess" what commits are breaking the project based on dev comments.
Glad you answered because now I'm at the point where it feels like unnecessary admin.
tonyp7
A major version update means breaking changes in the API according to semantic versioning (aka semver)
raralala1
my favorite
https://github.com/elysiajs/elysia/issues/867
semver is a convention, not a mandatory standard
danielcw189
I know that.
I don't know why you mention that in a reply to my comment
starsfan18
Is it in Rust yet?
[deleted]
_Kristian_ 1 points · 5d ago
⁶🤷⁷
crezza -9 points · 6d ago
Doesn’t say anything about that in the blog ?
SpoinkyNL 15 points · 6d ago
It's right there in the article: https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/?r#typescript-7.1-api
Typescript 7 didn't ship with these which meant tooling was largely stuck on 6.x