Add support for pre-release versions #131

New Issue

GiteaMirror · 2026-02-17T11:48:39-06:00

GiteaMirror commented

2026-02-17 11:48:39 -06:00

Originally created by @KevinGhadyani-minted on GitHub (Sep 14, 2021).

I'm not seeing anything about the -alpha, -beta, or -rc pre-release versions in Conventional Commits. These are part of SemVer v2: https://semver.org/ and would be fantastic to have available when working in a library.

Is it possible to add this to Conventional Comments as v1.1.0 or v2.0.0?

Originally created by @KevinGhadyani-minted on GitHub (Sep 14, 2021). I'm not seeing anything about the `-alpha`, `-beta`, or `-rc` pre-release versions in Conventional Commits. These are part of SemVer v2: https://semver.org/ and would be fantastic to have available when working in a library. Is it possible to add this to Conventional Comments as `v1.1.0` or `v2.0.0`?

GiteaMirror commented

2026-02-17 11:48:40 -06:00

@damianopetrungaro commented on GitHub (Sep 28, 2021):

Nice idea @KevinGhadyani-minted !
@bcoe do we wanna invest in this?

I think it could be a cool solution for a few issues we had in the past asking for pre-first release commit or similar.

@damianopetrungaro commented on GitHub (Sep 28, 2021): Nice idea @KevinGhadyani-minted ! @bcoe do we wanna invest in this? I think it could be a cool solution for a few issues we had in the past asking for pre-first release commit or similar.

GiteaMirror commented

2026-02-17 11:48:41 -06:00

@KevinGhadyani-minted commented on GitHub (Nov 15, 2021):

This is what we have now in Conventional Commits 1.0.0:

Type	Version Change
BREAKING CHANGE:	1.0.0
build:	0.0.0
chore:	0.0.0
ci:	0.0.0
docs:	0.0.0
feature:	0.1.0
fix:	0.0.1
perf:	0.0.0
refactor:	0.0.0
style:	0.0.0
test:	0.0.0

These are my proposed additions:

Type	Version Change
alpha BREAKING CHANGE:	1.0.0-alpha.0
alpha feat:	0.1.0-alpha.0
alpha fix:	0.0.1-alpha.0
alpha:	0.0.0-alpha.1
beta BREAKING CHANGE:	1.0.0-beta.0
beta feat:	0.1.0-beta.0
beta fix:	0.0.1-beta.0
beta:	0.0.0-beta.1
release candidate BREAKING CHANGE:	1.0.0-rc.0
release candidate feat:	0.1.0-rc.0
release candidate fix:	0.0.1-rc.0
release candidate:	0.0.0-rc.1

I have not added any specifications for meta data such as 0.0.0.alpha.1+exp.sha.5114f85, but that could possibly be handed by the scope or by some other way to identify meta data.

From Semantic Versioning 2.0.0:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
Source: https://semver.org/#spec-item-9

Since I've coded my own implementation of Conventional Commits using the semver package on npm, I'm going to be implementing this in my own project. If we want to change my proposal, please post in here so I can change mine to match the official spec.

@KevinGhadyani-minted commented on GitHub (Nov 15, 2021): This is what we have now in Conventional Commits 1.0.0: | Type | Version Change | | --- | --- | | BREAKING CHANGE: | 1.0.0 | | build: | 0.0.0 | | chore: | 0.0.0 | | ci: | 0.0.0 | | docs: | 0.0.0 | | feature: | 0.1.0 | | fix: | 0.0.1 | | perf: | 0.0.0 | | refactor: | 0.0.0 | | style: | 0.0.0 | | test: | 0.0.0 | These are my proposed additions: | Type | Version Change | | --- | --- | | alpha BREAKING CHANGE: | 1.0.0-alpha.0 | | alpha feat: | 0.1.0-alpha.0 | | alpha fix: | 0.0.1-alpha.0 | | alpha: | 0.0.0-alpha.1 | | beta BREAKING CHANGE: | 1.0.0-beta.0 | | beta feat: | 0.1.0-beta.0 | | beta fix: | 0.0.1-beta.0 | | beta: | 0.0.0-beta.1 | | release candidate BREAKING CHANGE: | 1.0.0-rc.0 | | release candidate feat: | 0.1.0-rc.0 | | release candidate fix: | 0.0.1-rc.0 | | release candidate: | 0.0.0-rc.1 | I have not added any specifications for meta data such as `0.0.0.alpha.1+exp.sha.5114f85`, but that could possibly be handed by the scope or by some other way to identify meta data. From Semantic Versioning 2.0.0: > A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. > Source: https://semver.org/#spec-item-9 Since I've coded my own implementation of Conventional Commits using the [`semver`](https://www.npmjs.com/package/semver) package on npm, I'm going to be implementing this in my own project. If we want to change my proposal, please post in here so I can change mine to match the official spec.

GiteaMirror commented

2026-02-17 11:48:42 -06:00

@marksy commented on GitHub (Oct 18, 2022):

Nice one @KevinGhadyani-minted this is what I'm looking for too.

I wonder if bracketing the release type, similar to scope, would be easier to read/parse?

type(scope)[release_type]: title so for example:

feat(navigation)[alpha]: new style of navigation === v0.1.0-alpha.0
fix(navigation)[beta]: navigation keyboard issue === v0.1.1-beta.0
docs(navigation)[rc]: how to use the new navigation === v1.0.0-rc.0

@marksy commented on GitHub (Oct 18, 2022): Nice one @KevinGhadyani-minted this is what I'm looking for too. I wonder if bracketing the release type, similar to scope, would be easier to read/parse? `type(scope)[release_type]: title` so for example: * `feat(navigation)[alpha]: new style of navigation` === `v0.1.0-alpha.0` * `fix(navigation)[beta]: navigation keyboard issue` === `v0.1.1-beta.0` * `docs(navigation)[rc]: how to use the new navigation` === `v1.0.0-rc.0`