Uniquely and safely version parallel feature/ bug fix development. #1082

Summary

What I am missing in semver is a way to uniquely identify and safely use builds of ongoing (parallel) development work.

Problem Statement

Let's say I have a base software 3.4.5.
When developing for an issue based on this version, I would create a branch and tag some or all of the (released) builds.

Things which will not work

What I can do now is to use 3.4.5+issueName.0, 3.4.5+issueName.1, ...
However, the comparison rules would make them all equal and even equal to 3.4.5, so I could not easily update in this versions during development and could even have this WIP thing installed and satisfy a 3.4.5 version requirement.

The other alternative would be to use e.g. 3.4.6-issueName.0, 3.4.6-issueName.1, ...
The problem with this is that, when I have multiple issueNames, they would be compared to each other, so an automatic dependency update might lead people to switch the development branch.

Temporarily switching the project name is not feasible if you want to publish this in repository, because you might to have register the name for that first, which is not feasible to do for all issue/ feature/ bug branches you might have.
Also it's problematic when having a dependency tree, which hopefully uses ^ or whatever and only one component in this tree requires it to be such a in-development variant.

Related Proposals

• Conventional Commits #410 is about commit messages
• How to tag official releases with added patch set #518 is about development in forks, which would not guarantee unique naming of the ongoing development work, so this has to be a separate project, which for sure could follow the versions of the base project.
• Supporting multiple versions and backporting fixes that introduce features or break things #532 is to many understanding mainly about having a problem, because semver would be applied to a project, which did not use it in the past and having to maintain these old versions.
• RFC: Forward-development or WIP (work-in-progress) support in Semantic Versioning #765 seems to be about linear further/ WIP development, while this here is about parallel ones (based on a common previous release)
• Support for more granular releases than <patch> level #803 is already answered and not really related to source variants/ development work.
• Support for "forked" semver format <semver><symbol><semver> #924 Is for real forks and there the comment that the package name should be switched, is absolutely also my opinion.
• Support multiple version axes #948 is about build variants, not development work/ changed source code.

Anti-Proposals

Naturally I would have proposed to add a + for that, but this is already used for builds, where I would have used something like #, so I go with the /, which seems to be already used in a lot of proposals.

Proposal

The pre-release now in there is optional and I just wanted to keep it in as an example.

My suggestion would be to use e.g. 3.4.5-rc.5 and a basis and result in 3.4.5-rc.5/myIssue,1.

Multi-Level variants might be selected by using . or further / (not sure here).

For version selection, the variant would have to be explicitly stated.

Tools listing/ proposing development versions would show them as potential "successors" of the semantic version stated before the /.
The , after the / might be used to number consecutive builds in this variant, so people can follow a developer easily.

So a 3.4.5-rc.5/myIssue,1 would be smaller than 3.4.5-rc.5/myIssue,2 and 3.4.5-rc.5/myIssue,2 bigger than 3.4.5-rc.5/myIssue,1.

For now I would not allowed "nested" versions, but allow to add further / and after them , to allow developing multiple proposals and name them in a transparent way.

Backwards compatibility

Due to the / in the semantic version, older tools would safely deny such versions.