mirror of
https://github.com/semver/semver.git
synced 2026-07-11 09:22:32 -05:00
[GH-ISSUE #479] Non-prerelease Versions Should Not Be Allowed to Use Prerelease Versions of Dependencies #1219
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1219
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 @Swivelgames on GitHub (Dec 5, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/479
There's a growing trend of projects being published under semver that depend on pre-release dependency versions, that cause compatibility issues as time goes on and those projects move out of pre-release. This is causing projects to "unknowningly" release versions that become incompatible and breaking later on due to their dependency on these pre-release versions.
No stable version should have a pre-release dependency, as that tarnishes the definition of "stable".
In my opinion, this should be dictated by semver. It's becoming a major problem for developers trying to work within a stable environment. Semver has already helped tremendously in alleviating these types of problems by properly defining versioning to prevent issues like this from occurring. This would be a huge leap in the right direction as we all continue to work towards ensuring stability in our projects.
@jwdonahue commented on GitHub (Dec 22, 2018):
Semver is all about the semantics and syntax of the version string, not how you manage dependency trees. That said, this might be good for inclusion in the FAQ.
@grv87 commented on GitHub (Aug 24, 2019):
I don't see the harm if the project's release used exact version of pre-release dependency.
The real problem is that the project should have been re-released when dependency reached stable stage.
@ghost commented on GitHub (Oct 13, 2019):
If a version of a dependency is pre-release, wouldn't the inclusion in a release build also constitute that the dep is release worthy? Therefore, everything including deps should be moved to at least 1.0.0?
@runeimp commented on GitHub (Oct 14, 2019):
Nothing about the state of your API, app, etc. should indicate anything about the state of its dependencies. The state of your product is the only thing that matters. If you feel your product is release worthy (pre-release or otherwise) that's your call. If a dependency is implemented in a way that it's version could change at a later date and then make your product fail should be avoided by locking the version of the dependency if your worried about such things. It may also be completely reasonable to assume that allowing the dependency to be upgraded at a later date is desirable. These are simply judgement calls based on many factors of the development process and the understanding of how your audience may use your product. And sometimes you can do everything as safe as possible and things still break down the line for reasons far beyond your control. There is no perfect system. SemVer is just a great start in trying to create a better system that most developers should be able to follow.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks everyone for contributions, you're amazing 🎆 Did you find any consensus?
@alexandrtovmach commented on GitHub (Jun 14, 2021):
Closing as staled, feel free to re-open or create a new issue 👻