Support Build-Metadata from SemVer 2.0

[exhuma]

If a package is re-released with differing build-metadata, the package is refused by verdaccio

According to paragraph 10 in SemVer 2.0, a version number can contain build-metadata:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Build metadata can be used effectively to mark changes which don't impact the source code. PEP-440 from Python explains this like this:

Some projects use post-releases to address minor errors in a final release that do not affect the distributed software (for example, correcting an error in the release notes).

In SemVer, a "post-release" could be denoted using build-metadata. Assume that you have a project in version 1.0.0 and notice an error in the API docs which you want to fix immediately. Using a post-release, this could be released as (SemVer compliant) 1.0.0+post.1.

However, publishing this on verdaccio will fail as it already has a 1.0.0 release.

Describe the solution you'd like

It would be nice if verdaccio would accept post-releases as they - per definition - have no code-changes and even replacing the existing files would be safe.

Describe alternatives you've considered

• We tried to drop the "post" release alltogether, but this still did not solve our problem of re-publishing a package for house-keeping tasks.
• We can use -f but this will also accept situations where it really should fail. We would like to only accept release overwrites if the build-metadata changes.