Post-Release versioning and SemVer 2.0 (sematic verisoning)

Question

this is not a coding, but rather a process question.

I am building software that might need a post-release fix or feature addition for certain markets or in general.

Following the SemVer 2.0 (http://semver.org/spec/v2.0.0-rc.2.html) scheme of appending a - tag to the designated version number to mark I would like to add a + tag to the version number to mark such a post-release version.

As long as no breaking change occurs this would result in the following version tree:

1.0.1-rc1                               // initial pre-release
|
1.0.1-rc2                               // second pre-release
|
1.0.1                                   // actual release
|
|-------- 1.0.1+1 --- 1.0.1+2           // post release path
|
|
|
1.0.2                                   //non breaking
|
2.1.0                                   //1st breaking

Is there a better way to do it fully semver compliant?

How will npm, jspm and yarn deal with such a semVer extension?

Am I missing a piece? Is there an "offical" solution?

Answer 1

following the semver spec, my proposal seems to be "invalid"

10. 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-]. Build metadata SHOULD be ignored when determining version precedence. Thus two packages with the same version, but different build metadata are considered to be the same version. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.