Proposal: Use a different versioning scheme

[kaisalmen]

The current situation is: If you upgrade from 1.83.12 to 1.83.16 it seems like a patch, but it really isn't. 😅 If I use ~1.83.12 as a version selector in a dependent project you expect non-breaking changes. The only way to prevent this right now is to pin-point it to a fixed version like this: 1.83.12.

What do you think about the following version scheme? 185.0.0 = [vscode-version].[mva-level-changes].[mva-bugfixes]

So, new features, breaking changes will be 185.1.0, and bug fixes 185.0.1 like in regular semantic versioning. The meaning of minor is a bit stretched here, but there is at least the possibility to distinguish.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[CGNonofr]

not stale!

[CGNonofr]

After some thinking, synchronizing the version with VSCode is an error... npm which uses semver is too restricting on version format and there is no ideal solution.

I see 2 issues with your suggestion:

• I see no way to mark a version as not backward compatible
• What will happen when VSCode releases the v1.100.0? 😨

So the solution is probably just to use semantic release and have a compatibility table somewhere (which can be automated)

What do you think?

[kaisalmen]

So the solution is probably just to use semantic release and have a compatibility table somewhere (which can be automated)

@CGNonofr If we want to rely on semantic versioning or let's say if dependent projects rely on it, there is no other way, I guess. 👍

[github-actions[bot]]

:tada: This issue has been resolved in version 2.0.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: