[GH-ISSUE #243] What to do if any project's dependency requires to add its version into the project's one? #5285

New Issue

GiteaMirror · 2026-06-15T11:33:37-05:00

GiteaMirror commented

2026-06-15 11:33:37 -05:00

Originally created by @dvorapa on GitHub (Jan 22, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/243

We call for a paragraph at the end of the specification clarifying, how to behave when any project's dependecy requires to add its version into the project's one. My proposal would look like this:

13. In the case when any project's dependecy requires to add its version into
the project's one, the version of the dependency MUST be added after the tilde letter.
The pattern should then look like `MAJOR.MINOR.PATCH~(dependency version string)`

This is separated part of the #168 issue. It needed to be separated, because the two use cases of the original issue changed to be really differrent.

Original comment on #168 by @glebm:

Here is a use case where we really do need the fourth number, as far as I can tell.
bootstrap-sass is an automatic conversion of bootstrap (written in Less) to Sass. Bootstrap uses semver, and bootstrap-sass maintains the same version number, but with the addition of the fourth number to specify Sass-specific version, in case we need to fix something specific to the Sass port, while keeping the same version of the framework. So for bootstrap 3.0.3, we would initially release 3.0.3.0 (rubygems standard, originally the only package repository supported by bootstrap-sass). Later, if a bug were discovered in the Sass code, we'd fix it and release 3.0.3.1, maintaining patch-level compatibility with bootstrap version.
SemVer spec does not seem to account for this use case, causing discovery problems with various implementations such as npm or composer.json.
Since 3.0.3.0 is not a valid SemVer version number, I initially had figured we had two options:
3.0.3-0 - turned out to be inadequate since the number after - is defined as pre-release.
3.0.3+0 - also inadequate, as two versions that differ only in the build metadata, have the same precedence
At the moment it appears SemVer does not provide a solution
The pragmatic programmer in me says the best answer would be to allow 3.0.3.0, as in Major -> Minor -> Patch -> Extra.

Created an idea in my head:

@glebm In my opinion, yours problem @glebm could be declared like + and - additions: It means with special sign (× or ÷ or ~ or something like it) and it could be declared as the case, which completely corresponds with yours case. So the version of your application should look like X.Y.Z~x.y.z (uppercase is the major application and lowercase is your addition under the major application).

Please share your opinion with us and think about it ;)

Originally created by @dvorapa on GitHub (Jan 22, 2015). Original GitHub issue: https://github.com/semver/semver/issues/243 We call for a paragraph at the end of the specification clarifying, how to behave when any project's dependecy requires to add its version into the project's one. My proposal would look like this: ``` 13. In the case when any project's dependecy requires to add its version into the project's one, the version of the dependency MUST be added after the tilde letter. The pattern should then look like `MAJOR.MINOR.PATCH~(dependency version string)` ``` This is separated part of the #168 issue. It needed to be separated, because the two use cases of the original issue changed to be really differrent. Original comment on #168 by @glebm: > Here is a use case where we really do need the fourth number, as far as I can tell. > bootstrap-sass is an automatic conversion of bootstrap (written in Less) to Sass. Bootstrap uses semver, and bootstrap-sass maintains the same version number, but with the addition of the fourth number to specify Sass-specific version, in case we need to fix something specific to the Sass port, while keeping the same version of the framework. So for bootstrap 3.0.3, we would initially release 3.0.3.0 (rubygems standard, originally the only package repository supported by bootstrap-sass). Later, if a bug were discovered in the Sass code, we'd fix it and release 3.0.3.1, maintaining patch-level compatibility with bootstrap version. > SemVer spec does not seem to account for this use case, causing discovery problems with various implementations such as npm or composer.json. > Since 3.0.3.0 is not a valid SemVer version number, I initially had figured we had two options: > 3.0.3-0 - turned out to be inadequate since the number after - is defined as pre-release. > 3.0.3+0 - also inadequate, as two versions that differ only in the build metadata, have the same precedence > At the moment it appears SemVer does not provide a solution > The pragmatic programmer in me says the best answer would be to allow 3.0.3.0, as in Major -> Minor -> Patch -> Extra. Created an idea in my head: > > @glebm In my opinion, yours problem @glebm could be declared like + and - additions: It means with special sign (× or ÷ or ~ or something like it) and it could be declared as the case, which completely corresponds with yours case. So the version of your application should look like X.Y.Z~x.y.z (uppercase is the major application and lowercase is your addition under the major application). Please share your opinion with us and think about it ;)

GiteaMirror added the question staled labels 2026-06-15 11:33:37 -05:00

GiteaMirror closed this issue

2026-06-15 11:33:39 -05:00

GiteaMirror commented

2026-06-15 11:33:40 -05:00

@JamesMGreene commented on GitHub (Jan 22, 2015):

For reference, also see some good discussion in #242.

@JamesMGreene commented on GitHub (Jan 22, 2015): For reference, also see some good discussion in #242.

GiteaMirror commented

2026-06-15 11:33:41 -05:00

@glebm commented on GitHub (Mar 16, 2015):

Also see this blog post about the latest release of Bootstrap and what we had to do: http://blog.getbootstrap.com/2015/03/16/bootstrap-3-3-4-released/

@glebm commented on GitHub (Mar 16, 2015): Also see this blog post about the latest release of Bootstrap and what we had to do: http://blog.getbootstrap.com/2015/03/16/bootstrap-3-3-4-released/

GiteaMirror commented

2026-06-15 11:33:42 -05:00

@jwdonahue commented on GitHub (Dec 8, 2017):

@dvorapa, this issue is rotting on the vine. Very little engagement from the community and no related PR's that I am aware of. Unless you intend to pursue this issue further, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 8, 2017): @dvorapa, this issue is rotting on the vine. Very little engagement from the community and no related PR's that I am aware of. Unless you intend to pursue this issue further, please close this issue at your earliest possible convenience.

GiteaMirror commented

2026-06-15 11:33:45 -05:00

@dvorapa commented on GitHub (Jan 12, 2018):

This was requested by so many people in so many GitHub issues to SemVer, that I consider this a high priority issue

@dvorapa commented on GitHub (Jan 12, 2018): This was requested by so many people in so many GitHub issues to SemVer, that I consider this a high priority issue

GiteaMirror commented

2026-06-15 11:33:47 -05:00

@alexandrtovmach commented on GitHub (Jun 10, 2020):

This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing 🎆

@alexandrtovmach commented on GitHub (Jun 10, 2020): This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing :fireworks:

GiteaMirror commented

2026-06-15 11:33:47 -05:00

@alexandrtovmach commented on GitHub (Jun 19, 2020):

👻 👻 👻
Closed as staled

@alexandrtovmach commented on GitHub (Jun 19, 2020): 👻 👻 👻 Closed as staled

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5285