Customize default pre-release identifier
See original GitHub issueHi,
As stated in the doc, the default pre-release identifier is alpha.0, is there any way change it to preview or something else ?
Example :
| * 'Commit # 1'
| * 'Commit # 2 (tag: v1.1.0)' => v.1.1.0
| * 'Commit # 3' => v.1.1.1-alpha.0.1
| * 'Commit # 4' => v.1.1.1-alpha.0.2
What I would like is :
| * 'Commit # 1'
| * 'Commit # 2 (tag: v1.1.0)' => v.1.1.0
| * 'Commit # 3' => v.1.1.1-preview.1
| * 'Commit # 4' => v.1.1.1-preview.2
I know that this will (almost) work :
| * 'Commit # 1'
| * 'Commit # 2 (tag: v1.1.0)' => v.1.1.0
| * 'Commit # 3 (tag: v1.1.1-preview)' => v.1.1.1-preview
| * 'Commit # 4' => v.1.1.1-preview.2
But I’ll have to create a new preview tag after each RTM tag…
My researches pointed me out to
and
I think I’ll need to introduce 2 new vars here and override those default values with new ones if corresponding settings are found.
What do you think ? Can this be done this way ? Is there any better way ? I’ll be glad the submit a PR if you’re ok to accept this new little feature.
Thanks in advance for your support and thanks and lot for this very useful lib.
Best regards, Selmir
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Identify a Prerelease Version
A component version is identified as a prerelease when the prerelease key is assigned a user-defined identifier, such as -beta.2 , or the...
Read more >Are there npm version prerelease identifiers?
No, there are no npm version prerelease identifiers supported by the npm version command. You can see the reasoning by the team here: ......
Read more >Workflow configuration - semantic-release - GitBook
The release workflow is configured via the branches option which accepts a single or an array of branch definitions. Each branch can be...
Read more >Semantic Versioning 2.0.0 | Semantic Versioning
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release...
Read more >Prereleases and Npm
By default, prerelease versions are not included in a range. ... of dot separated identifiers immediately following the patch version.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

I like that a lot. That seems like exactly what I want. The current behavior alpha.0, alpha.1, etc is great. But it’d be nice to customize the token that gets appended there: alpha, beta, preview, etc.
Re, thanks for you answer and thoughts.
Your proposition is better than mine, but not exactly what my team wants.
In our current workflow, we only use tags for production releases
v1.1.1,v1.1.2etc, and each commit between two releases is pushed as apreviewpackage. You solution will result to all our preview versions to bevX.X.X-preview.0.Xinstead ofvX.X.X-preview.XI know that the issue here is not with MinVer but with our shitty old workflow, I think we can live with this extra
0in our previews version number.I’ll try to implement this feature as you proposed and submit a PR when it’s ready.
Thanks for your time 😃