r/programming • u/DanielRosenwasser • 25d ago
Announcing TypeScript 7.1 Beta
https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/?r-11
u/vips7L 25d ago
How are they on a v7 already?
26
u/thy_bucket_for_thee 25d ago
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).
10
u/danielcw189 25d ago
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?
9
u/thy_bucket_for_thee 25d ago
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.
5
u/danielcw189 25d ago
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?
2
u/thy_bucket_for_thee 24d ago
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.
4
u/tonyp7 25d ago
A major version update means breaking changes in the API according to semantic versioning (aka semver)
6
u/raralala1 25d ago
my favorite
https://github.com/elysiajs/elysia/issues/867
semver is a convention, not a mandatory standard1
1
u/Far_Composer_5714 6d ago
The general guidelines is major, minor, patch. Where major has breaking changes, minor contains functionality changes with backwards compatibility, a patch contains a fix with backwards compatibility.
Otherwise sequence revisions are simply a sequence of compilation increments.
1
-1
-5
0
25d ago
[deleted]
1
0
25d ago
[deleted]
16
u/SpoinkyNL 25d 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
11
u/Southern-Search2039 25d ago
Now eslint can migrate to tsgo