Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag prefix #1092

Merged
merged 5 commits into from Mar 6, 2022
Merged

Tag prefix #1092

merged 5 commits into from Mar 6, 2022

Conversation

blast-hardcheese
Copy link
Contributor

@blast-hardcheese blast-hardcheese commented Mar 3, 2022

Extending #1084 with the rest of #935

  • Include a configuration option to filter the draft tag by a static string prefix

The benefit of this is that if you use a tag-template: foo-v$RESOLVED_VERSION and tag-prefix: foo-v, prerelease versioning will be supported no matter the tag-template

@jetersen
Copy link
Member

jetersen commented Mar 3, 2022

feel free to rebase :)

@jetersen jetersen added the type: feature New feature or request label Mar 3, 2022
@blast-hardcheese blast-hardcheese marked this pull request as ready for review March 4, 2022 00:18
@blast-hardcheese
Copy link
Contributor Author

@jetersen Alright, ready. I'm available if there are any changes required, but I did remember to regenerate schema this time. Thank you in advance!

@jetersen jetersen merged commit 2220ef1 into release-drafter:master Mar 6, 2022
@blast-hardcheese blast-hardcheese deleted the tag-prefix branch March 6, 2022 16:57
@mkurz
Copy link
Contributor

mkurz commented Mar 11, 2022

A benefit of this is that if you use a tag-template: v$RESOLVED_VERSION and tag-prefix: v, prerelease versioning will be supported

Can you please explain (and maybe give an example) how prerelease versioning will be supported that way? Maybe I just don't get it...

@blast-hardcheese
Copy link
Contributor Author

@mkurz Heh, I think I need to edit that comment. When using the tag prefix versioning, (eg: foo-v1.2.3-rc1), prerelease versioning can't be parsed.

Compare

> semver.parse('abc-v1.2.3-rc1')
null
> semver.parse('1.2.3-rc1')
SemVer {
  major: 1,
  minor: 2,
  patch: 3,
  prerelease: [ 'rc1' ],
...

I didn't see any special-casing for stripping the leading v out of something like v1.2.3-rc1, so I presumed that I'd just not hit that edge case yet, since the fallback after semver.parse is semver.coerce:

> semver.coerce('foo-1.2.3-rc1')
SemVer {
  major: 1,
  minor: 2,
  patch: 3,
  prerelease: [],
...

I was operating under the incorrect assumption that any string prefix to the version passed into semver.parse would cause coerce to be used, which I now see is incorrect.

Sorry for the confusion, certainly it doesn't seem necessary if you're using vX.Y.Z-rcA-style versioning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants