adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-04 09:32:21 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Enhancement: Support VS Code Pre-Releases #683

New Issue
Closed
opened 2026-10-05 03:00:15 +02:00 by adam · 1 comment
adam commented 2026-10-05 03:00:15 +02:00
Owner
Copy link
Copy source

You have two separate versions, which is not good. For quite some time already, VS Code has supported pre-releases, which comes with many benefits such as a consolidated installations number, ratings, etc.

You have two separate versions, which is not good. For quite some time already, VS Code has supported pre-releases, which comes with many benefits such as a consolidated installations number, ratings, etc. <!-- github-sync-id:2590353826 -->
adam closed this issue 2026-10-05 03:00:15 +02:00
adam commented 2026-10-05 03:00:16 +02:00
Author
Owner
Copy link
Copy source

I know, but the biggest issue with pre-releases is that they need to follow sem versioning. Sem version pre-release tags on the versioning are not supported like in npm.

So, if you want to prepare for a 10.5.0 release, you must release all your "pre-releaseson10.4.x, or follow the suggested strategy from VS Code: major.EVEN_NUMBER.patchfor release versions andmajor.ODD_NUMBER.patch for pre-release versions.

Both, in my opinion, are not great for a good sem versioning strategy as I want to bundle multiple changes in a new release version (if it is not a bug fix) and keep a clean changelog.

That is why there is a beta version: to keep the main version following a good sem versioning strategy and have a changelog file that can follow each version release.

I know, but the biggest issue with pre-releases is that they need to follow sem versioning. Sem version pre-release tags on the versioning are not supported like in **npm**. So, if you want to prepare for a `10.5.0` release, you must release all your "pre-releases` on `10.4.x`, or follow the suggested strategy from VS Code: `major.EVEN_NUMBER.patch` for release versions and `major.ODD_NUMBER.patch for pre-release versions. Both, in my opinion, are not great for a good sem versioning strategy as I want to bundle multiple changes in a new release version (if it is not a bug fix) and keep a clean changelog. That is why there is a beta version: to keep the main version following a good sem versioning strategy and have a changelog file that can follow each version release. <!-- github-comment-id:2415891684 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#683