mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #65] Internal vs. Public for Open Source #2766
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2766
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 @danielmarbach on GitHub (Jan 17, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/65
SemVer is pretty explicit about public APIs. My opinion is that if an open source project is internalizing everything it makes it pretty hard for the users of that library in case of bugs to quickly switch out internal components with a bug fix and then wait for the official release. That's why I'm not a fan of internalizing stuff. Why not take another approach in open source. My suggesting would be to add an exception clause so that public APIs can be put into an "Internals" namespace and then by convention can be considered to break without having to increment major numbers. Just an idea...
@hwinkel commented on GitHub (Jan 20, 2013):
I would agree, hiding internals in open source project should not happen. But this is more about clean code structure, documentation and communication. In terms of the APIs I think in open source projects you also have just user of the given project or library, not everybody want to dive into internals of a given open source project. Many people just want to use it and want to trust a given API.
@haacked commented on GitHub (Mar 13, 2013):
Yeah, the focus of SemVer is really on the unit of release (typically packages). I think adding the concept of internals just adds more unecessary complications to the spec and should be out of scope of what SemVer covers.
@danielmarbach commented on GitHub (Mar 13, 2013):
Just because of complexity? is this your only argument?
@haacked commented on GitHub (Mar 13, 2013):
Isn't that good enough? 😉
Let me ask you, what would the exception clause say? How would that be reflected in the actual version number? The point of SemVer is to communicate expectations.
How would I know that mulitple versions of your package will break even though the
MAJORversion is not incremented vs all the others?If you have a set of APIs that should be allowed to break, perhaps put those in a pre-release package and reference them from the other package. Or make the whole thing pre-release.