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

ReleaseNotes.load does not parse SemVer correctly #2557

Closed
Freymaurer opened this issue Nov 19, 2020 · 6 comments · Fixed by #2686
Closed

ReleaseNotes.load does not parse SemVer correctly #2557

Freymaurer opened this issue Nov 19, 2020 · 6 comments · Fixed by #2686

Comments

@Freymaurer
Copy link
Contributor

Freymaurer commented Nov 19, 2020

Description

I used ReleaseNotes.load to read in my markdown release notes and tried to add the github commit to the SemVer metadata. As "#" is not a allowed symbol in metadata the version looks like this 0.1.1+09da94a.

let release = ReleaseNotes.load "RELEASE_NOTES.md"

release.SemVer.BuildMetaData returns in this case 09
release.SemVer.Original returns in this case 0.1.1+09

if i change the SemVer to 0.1.1+test it returns nothing for meta data.

Repro steps

  1. Create RELEASE_NOTES.md with
### 0.1.1+09da94a (Released 2020-11-18)
* TestDes.:
    * TestSubDesc
  1. Parse the markdown file with ReleaseNotes.load "RELEASE_NOTES.md"

  2. Check SemVer.BuildMetaData/SemVer.Original of the ReleaseNotes record type.

Expected behavior

As far as i understand the specification it should allow both numbers and letters for
metadata.

Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-].

Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

Actual behavior

It stops parsing the metadata at the first letter.

@github-actions
Copy link
Contributor

Welcome to the FAKE community! Thank you so much for creating your first issue and therefore improving the project!

@github-actions
Copy link
Contributor

There has not been any activity in this issue for the last 3 months so it will be closed in 14 days if there is no activity.

@github-actions github-actions bot added the stale label Feb 19, 2021
@Freymaurer
Copy link
Contributor Author

Freymaurer commented Feb 19, 2021

Okay, so i looked a bit into this:

The problem seems to be that SemVer is parsed from the nuget version

static member New(assemblyVersion,nugetVersion,date,notes) = { 
  AssemblyVersion = assemblyVersion
  NugetVersion = nugetVersion
  SemVer = SemVer.parse nugetVersion
  Date = date
  Notes = notes }

and nuget seems to get parsed with this Regex pattern: ([0-9]+.)+[0-9]+(-[a-zA-Z]+\d*)?(.[0-9]+)?, which does actually not hit any metadata and is faulty as it will parse wrong patterns.

My suggestion would be to use the offcially recommended Regex to parse SemVer. Either by parsing the full header for SemVer again or by using it to also parse the nuget version.

In the following i removed starting and ending requirement to confidently pick the complete SemVer from the start line.

(?<major>0|[1-9]\d*)\.(?<minor>0|[1-9]\d*)\.(?<patch>0|[1-9]\d*)(?:-(?<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?

You can check this regex against some examples:

### 0.1.1+7c567fd (Released 2020-11-18)

### 0.2.0+899b535 (Released 2021-1-11)

### 0.3.0+0d31c43 (Released 2021-2-11)

### 0.3.1+cbc655c (Released 2021-2-12)

1.0.0-alpha+001
1.0.0+20130313144700, 
1.0.0-beta+exp.sha.5114f85
1.0.0+21AF26D3—-117B344092BD

@Freymaurer
Copy link
Contributor Author

Would it help if i did a PR for this? There are some open PRs and i don't really know if this would be useful.

@aggieben
Copy link

I think this may still be an issue and should be reopened.

@Freymaurer
Copy link
Contributor Author

Yes sadly it is 😢 I am also having an eye on this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants