[GH-ISSUE #1082] Uniquely and safely version parallel feature/ bug fix development. #2397

New Issue

GiteaMirror · 2026-04-20T10:24:38-05:00

GiteaMirror commented

2026-04-20 10:24:38 -05:00

Originally created by @torsknod2 on GitHub (Feb 22, 2025).
Original GitHub issue: https://github.com/semver/semver/issues/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.

#410 is about commit messages
#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.
#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.
#765 seems to be about linear further/ WIP development, while this here is about parallel ones (based on a common previous release)
#803 is already answered and not really related to source variants/ development work.
#924 Is for real forks and there the comment that the package name should be switched, is absolutely also my opinion.
#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.

Originally created by @torsknod2 on GitHub (Feb 22, 2025). Original GitHub issue: https://github.com/semver/semver/issues/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 `issueName`s, 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 * #410 is about commit messages * #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. * #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. * #765 seems to be about linear further/ WIP development, while this here is about parallel ones (based on a common previous release) * #803 is already answered and not really related to source variants/ development work. * #924 Is for real forks and there the comment that the package name should be switched, is absolutely also my opinion. * #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.

GiteaMirror commented

2026-04-20 10:24:38 -05:00

@steveklabnik commented on GitHub (Feb 24, 2025):

Semver is inherently about released software that you are making API guarantees for for your users. I'm not going to close this immediately, but we're not going to be making big changes like adding something like , and /.

@steveklabnik commented on GitHub (Feb 24, 2025): Semver is inherently about *released* software that you are making API guarantees for for your users. I'm not going to close this immediately, but we're not going to be making big changes like adding something like `,` and `/`.

GiteaMirror commented

2026-04-20 10:24:39 -05:00

@Joe1the2Creator3 commented on GitHub (Apr 18, 2025):

[System.Obsolete("Regex.CompileToAssembly is obsolete and not supported. Use the GeneratedRegexAttribute with the regular expression source generator instead.", DiagnosticId="SYSLIB0036", UrlFormat="https://aka.ms/dotnet-warnings/{0}")]
public static void CompileToAssembly(System.Text.RegularExpressions.RegexCompilationInfo[] regexinfos, System.Reflection.AssemblyName assemblyname, System.Reflection.Emit.CustomAttributeBuilder[]? attributes, string? resourceFile);

@Joe1the2Creator3 commented on GitHub (Apr 18, 2025): [System.Obsolete("Regex.CompileToAssembly is obsolete and not supported. Use the GeneratedRegexAttribute with the regular expression source generator instead.", DiagnosticId="SYSLIB0036", UrlFormat="https://aka.ms/dotnet-warnings/{0}")] public static void CompileToAssembly(System.Text.RegularExpressions.RegexCompilationInfo[] regexinfos, System.Reflection.AssemblyName assemblyname, System.Reflection.Emit.CustomAttributeBuilder[]? attributes, string? resourceFile);

GiteaMirror commented

2026-04-20 10:24:41 -05:00

@jwdonahue commented on GitHub (Aug 28, 2025):

@torsknod2, your proposed changes to the SemVer spec, would be a breaking change. The proposed workflow can easily be supported, using SemVer 2 in your automation, by dropping the forward slashes and using the standard dots in their place. This of course, does not imply that existing packaging or related tooling, will directly support whatever it is you have in mind. Even if you successfully pushed your new version of SemVer, it does NOT imply that any particular tool publisher or package repository, will decide to support that new version.

You are allowed to define whatever prerelease and build meta tag formats, that works for your processes. If you allow a fixed set of prefix fields in your prerelease tag, followed by one or more '.issue.v' pairs of fields, then you should be able to adapt your own tooling and internal processes accordingly.

I highly recommend that you do not push/pull, anything like what you seem to be proposing, to/from a public repository. Your internal build and test cycles, should be isolated to the fullest extent possible, from all public package repositories. Even when dependent on third party packages, your internal build processes, should pull them from a secure, internal location, that has been populated with properly scanned and tested articles.

@jwdonahue commented on GitHub (Aug 28, 2025): @torsknod2, your proposed changes to the SemVer spec, would be a breaking change. The proposed workflow can easily be supported, using SemVer 2 in your automation, by dropping the forward slashes and using the standard dots in their place. This of course, does not imply that existing packaging or related tooling, will directly support whatever it is you have in mind. Even if you successfully pushed your new version of SemVer, it does NOT imply that any particular tool publisher or package repository, will decide to support that new version. You are allowed to define whatever prerelease and build meta tag formats, that works for your processes. If you allow a fixed set of prefix fields in your prerelease tag, followed by one or more '.issue.v' pairs of fields, then you should be able to adapt your own tooling and internal processes accordingly. I highly recommend that you do not push/pull, anything like what you seem to be proposing, to/from a public repository. Your internal build and test cycles, should be isolated to the fullest extent possible, from all public package repositories. Even when dependent on third party packages, your internal build processes, should pull them from a secure, internal location, that has been populated with properly scanned and tested articles.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2397