mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #397] Here is a question. #5414
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5414
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 @zzc-tongji on GitHub (Sep 29, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/397
I've got an application (MYDICTIONARY-LOCAL-CLI) and a library (MYDICTIONARY). The application use the API provided by the library.
I just fix a small bug in the library and there is no change in the API. So I need to change the version from v1.0.0 to v 1.0.1. However, there is a question: should I modify the version of the application?
There is no change in the source code of the application, so the modification is not necessary. However, the release of the application is changed, so the version of the application should be modified to v1.0.1.
What should I do?
@robpark commented on GitHub (Sep 29, 2017):
Assuming that's a build time library and you need to build and release your
app, then absolutely, you want to bump the patch number of the app as well.
E.g. If it was 1.0.6, then release 1.0.7. Side note: the version of the
library and the app should not be kept in "lock step". They should be
allowed to drift apart depending on each context.
On Fri, Sep 29, 2017 at 1:19 AM Zhicheng Zhang notifications@github.com
wrote:
@zzc-tongji commented on GitHub (Sep 30, 2017):
I got it.
I should not modify the version of the application.
Thanks.
@GoLangsam commented on GitHub (Sep 30, 2017):
@zzc-tongji
Not sure.
If You re-release the app as a new binary (including the changed lib),
You'd better bump the patch number.
@robpark commented on GitHub (Oct 1, 2017):
@GoLangsam .. correct. 👍
@mmlinford commented on GitHub (Oct 2, 2017):
Even if it's dynamically linked?
@robpark commented on GitHub (Oct 2, 2017):
That's an interesting question. I suppose then wouldn't it just depend on how you actually release.
Do you release them independently? If yes, then perhaps it's more analogous to service A depending on service B and both release independently and maintain their own version numbers. In that case it sounds like the app depending on the dynamic lib wouldn't get bumped.
If they're released in lock-step however, meaning dynamic or not, you always re-release the app to deploy the new library, then I think I'd bump the app's version, since it's in effect changed.
I'm interested in how others have handled that.
@markembling commented on GitHub (Oct 2, 2017):
I agree with this approach. If the application must be released along with the library (regardless of how it might be linked), I would increment the app version. Only if the two are distributed separately (or at least the library update was outside the update cycle for the application) would I not do that.
@usta commented on GitHub (Oct 25, 2017):
I suggest adding those kinds of questions and their answers to semver document
@jwdonahue commented on GitHub (Nov 28, 2017):
The underlying question here, is what should be versioned? If it changed, it should get some kind of version bump. If the application didn't change, then it's version shouldn't either, but if you ship a package that includes the application and the library/dll, that package must definitely get a version bump. We don't bump any versions of our packages/apps/docs/libs when the OS gets updated for instance, or when a remote service is updated, we have no control and imperfect knowledge of those changes, and we are not responsible for them. What we include in our delivery packages however, is our responsibility, and we MUST always bump to the appropriate version level (maj.min.patch) when we make changes.
@jwdonahue commented on GitHub (Dec 27, 2017):
@zzc-tongji, to put it another way, no two packages with different content, should ever have the same name and version labeling on them.
Unless you have further questions, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Jul 14, 2018):
@zzc-tongji, do you have additional question? If not, please close this issue at your earliest possible convenience.
@Haacked, I think this question has been answered, time to close.