mirror of
https://github.com/semver/semver.git
synced 2026-03-22 22:20:28 -05:00
SemVer Spec - Override Extension #148
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#148
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @christian-weiss on GitHub (Aug 29, 2014).
If your project (1.0.0) depends on a FooPackage (v 1.2.3) which itself depends on a BarPackage (v 2.5.1) and you may identify a bug in BarPackage. You normally start a fork of BarPackage to fix it and send a pull-request to the maintainer of BarPackage. If you can not wait till the maintainer of the BarPackage integrates it you need to fork FooPackage to update the dependency from BarPackage to ForkOfBarPackage and your project dependencies from FooPackage to ForkOfFooPackage.
Imagine the amount of changed if the dependency chain is longer than that. And after integration you need to update dependency back to the initial definition.
From my point of view a good dependency management software (composer, etc.) should give you an option to force overriding of dependency definition at each level in the dependency chain (without forking the full dependency chain) . I think is is not a direct issue to semver itself. But as discussed earlyer (see other issues, e.g. #17) there is need to solve that issue.
If we provide a "override extension" spec, we can avoid confusion (here and elsewhere). This would enable use to focus on semantic issues instead of hacking semver to fit to some special cases, that can be solved elsewhere best. When promoting it is a valid job for a dependency manager and if we provide a spec that has the chance to introduce a standard way of declaring that override rules accross all dependency management tools - it can lead to an more focues discussion an the semver spec itself.
The override spec MAY include a behavior spec e.g. to warn if a sub project changes the dependency to another project which may makes our override rule obsolete. In such a case i would ask a human to update / review dependency definition and override rules.
@dvorapa commented on GitHub (Aug 31, 2014):
Do you know Dart programming language? This language and its package manager does exactly, what you say. You do not need to fork all of that dependencies, you just could set that exact file from exact dependency package should be overwritten by your modified file. As you say. It's not a mistake of semver, but to my mind it's a mistake of the each package manager (composer eg), because some of them (Dart package manager) implements this feature in a correct way (see https://www.dartlang.org/tools/pub/dependencies.html#dependency-overrides).
I think you should fill in a bug in the bug tracker of your favourite package manager. You should ask for the same feature, which works in Dart package manager.
@jwdonahue commented on GitHub (Dec 7, 2017):
@christian-weiss, unless you have questions or intend to issue a PR against this issue, please close it. It is quite old and unlikely to spur any changes in the spec an the issue currently delineated.
@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 🎆
@christian-weiss commented on GitHub (Jun 10, 2020):
Sure it could be solved on every single package manager but i still believe having that included as an topic in SemVer would introduce a kind of standard across all package managers. Sadly my time was very limited so i was not able to make contributions.
Looks like no one else is interested in this topic. So i close this ticket now.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
@christian-weiss I'm so sorry for that, probably when we will complete "reviving process"(https://github.com/semver/semver/issues/573), community become more active and you can create new issue to force your idea.