question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Customize default pre-release identifier

See original GitHub issue

Hi,

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

https://github.com/adamralph/minver/blob/1d2aee6b50e691ed25eea75141ef1991a4e0ee7f/MinVer.Lib/Version.cs#L16

and

https://github.com/adamralph/minver/blob/1d2aee6b50e691ed25eea75141ef1991a4e0ee7f/MinVer.Lib/Version.cs#L109-L122

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:closed
  • Created 4 years ago
  • Comments:5 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
fuzzzerdcommented, Jul 24, 2019

It may even be better to restrict customisation to only the pre-release phase, i.e. alpha vs preview. In that case, you would specify something like:

<MinVerDefaultPreReleasePhase>preview</MinVerDefaultPreReleasePhase>

That would result in the default pre-release identifiers being preview.0 instead of alpha.0.

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.

1reaction
Selmirrrrrcommented, Jul 24, 2019

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.2 etc, and each commit between two releases is pushed as a preview package. You solution will result to all our preview versions to be vX.X.X-preview.0.X instead of vX.X.X-preview.X

I know that the issue here is not with MinVer but with our shitty old workflow, I think we can live with this extra 0 in 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 😃

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found