Shields: NuGet badges with build metadata treated as pre-release

[Turnerj]

Are you experiencing an issue with...

• [x] [shields.io](https://shields.io/#/)

:beetle: Description

I've been using build metadata in my NuGet package versioning since mid-May (eg. 0.11.0+294) and that has been accessible via the "/v/" path for NuGet. My last successful version number that appeared under the "/v/" path was 0.16.0+388.

In my next version, my build information is 0.17.0+1b81349-429 which follows semver rule #10 for Build Metadata. This build does not appear under "/v/" but under "/vpre/".

I can obviously just use the "/vpre/" URLs but the thing is, that build number isn't any less of a pre-release than 0.16.0+388 is (in that both are major version zero).

If there is a change that major version zero now needs "/vpre/", that's fine. I think that 0.16.0+388 shouldn't appear under "/v/" though.

EDIT: Just to add to the confusion, I have another library (see the second 2 badges) which use the same version number structure as what I've mentioned already but it appears fine under "/v/".

Should I be blaming caching?

:link: Link to the badge

[calebcartwright]

Took a look at this one, and it seems it's a combination of how Shields is attempting to determine whether a nuget package version is a prerelease version, as well as the various versions you've published for the two packages.

The reason why the behavior is different between your two packages is that all of the published versions for second package (CacheTower) have a build metadata that includes the -, whereas your first package (MongoFramework) has other versions that do not.

MongoFramework versions:

[ 
  { 
    "version":"0.5.0"
  },
  { 
    "version":"0.6.0"
  },
  { 
    "version":"0.7.0"
  },
  { 
    "version":"0.7.1"
  },
  { 
    "version":"0.7.3"
  },
  { 
    "version":"0.7.4"
  },
  { 
    "version":"0.8.0"
  },
  { 
    "version":"0.9.0"
  },
  { 
    "version":"0.10.0"
  },
  { 
    "version":"0.11.0+294"
  },
  { 
    "version":"0.11.1+299"
  },
  { 
    "version":"0.11.2+329"
  },
  { 
    "version":"0.12.0+334"
  },
  { 
    "version":"0.13.0+341"
  },
  { 
    "version":"0.14.0+363"
  },
  { 
    "version":"0.15.0+377"
  },
  { 
    "version":"0.16.0+388"
  },
  { 
    "version":"0.17.0+1b81349-429"
  },
  { 
    "version":"0.18.0+1906848-444"
  }
]

CacheTower Versions

[ 
  { 
    "version":"0.1.1+148c49b-52"
  },
  { 
    "version":"0.1.2+e707a3f-61"
  }
]

In cases where the user has selected v (and not vpre) for a version badge, but the specified package only has prerelease versions, Shields will typically go ahead and display the latest prerelease version badge anyway (instead of throwing an error for example).

Versioning of nuget packages is pretty inconsistent from what I've seen (for example I do not believe semver is enforced), so Shields is currently using the presence of the - character in nuget package versions to attempt to determine if a version is prerelease or not:
https://github.com/badges/shields/blob/f82f7b798d522c1dda9294796c81ace926f2a435/services/nuget/nuget-v3-service-family.js#L186-L198

So in the case of your MongoFramework package, Shields is (incorrectly) of the belief that there are 2 pre-release versions (0.17.0+1b81349-429 and 0.18.0+1906848-444), and that all of the other versions are release, the most recent release version being what you see on the badge (0.16.0+388). In the case of your CacheTower package, Shields is (again incorrectly) determining that _all_ of the package versions are pre-release version, so it's giving you the latest pre-release version anyway.

[calebcartwright]

On second thought, although I generally think of any v0.x version as pre-release, is that actually true?
Is 0.16.0+388 technically a "release" semver version with build metadata on the patch?

Edit - it looks like we're already handling nuget version badges differently (yellow color for example), so I'm just going to fix the incorrect handling of the - in the build metdata

[Turnerj]

Thank you for jumping on this so fast and providing me with so much detail, I really appreciate it. 🙂