mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #286] Multiple APIs in one project #5323
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5323
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 @Storyyeller on GitHub (Nov 24, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/286
What if a single project contains multiple, largely independent APIs? It seems like it makes more sense to version them independently since users of A won't care about breaking changes to B. But then how do you label releases? If you have a release with version 1.0.4 of A and 3.2.1 of B, what do you call it?
@FichteFoll commented on GitHub (Nov 24, 2015):
AB 4.2.2 maybe.
I would consider this project a combination of A and B with their public APIs combined. That means, if you bump major or minor in any of A or B, you need to bump it in AB too.
On a major update of B and thus also AB, 'users' of "just A" will need to verify that either their API didn't update or that the update didn't break their use of its API.
That's assuming they really need to be in one project and cannot be separated, which seems like the proper way to me.
@crazedsanity commented on GitHub (Dec 1, 2015):
There are a lot of projects that are versioned and are the combination of smaller projects/libraries. I have several of my own, and I've contributed to several. The main project should have it's own version, independent of those smaller libraries.
Generally, if there's an update to those libraries, it ends up being at least a patch release to the main project. If A has a major release (say
0.1.0->1.0.4), B has a minor release (say3.1.0->3.2.1), and C has a patch-level release (say1.0.1->1.0.2), the main project might have a major, minor, or just patch-level version bump.It all depends upon the net effect on the main project.
@jwdonahue commented on GitHub (Dec 9, 2017):
@Storyyeller, unless you have more questions, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Oct 8, 2018):
@Storyyeller, semver is all about labeling each of the nodes in the dependency graph with a version string, not how to manage the graph itself. Please close this issue.