mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #285] When adding a translation is it a Minor or Patch Release? #4449
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4449
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 @salcode on GitHub (Nov 23, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/285
I have a new translation I'm adding to a project. Is this best treated as a minor or patch release?
@haacked commented on GitHub (Nov 30, 2015):
Huh? Translations do not increment the version of Semver. Also, the translation should be submitted to https://github.com/mojombo/semver.org not this repo.
@salcode commented on GitHub (Nov 30, 2015):
Hi @Haacked
Thank you for taking the time to answer my question with
To clarify, this is exactly the question I was trying to answer but I failed to come to this same conclusion based on the Semver Specification, which is why I created this issue. I am looking for clarification on the Semver Specification.
Do you consider "Translations do not increment the version of Semver" a general rule for Semver or is this specific to the semver.org repo?
In my case, I was releasing an update to a WordPress plugin due to a new translation and was unsure how to increment the version number. I don't think not incrementing the version number in this case makes sense but I'm certainly interested in your thoughts on the matter.
Thanks.
@crazedsanity commented on GitHub (Nov 30, 2015):
It would seem to me that, in this case, it would be prudent to update the patch version. This way it is more evident that there's a change for which the user can get an update.
@haacked commented on GitHub (Nov 30, 2015):
Probably a general rule, but it depends on the system.
The rule in my mind is, does the library change because of the translation? In the case of SemVer, the translation doesn't change the behavior of the SemVer spec so there's no need to patch it.
For libraries, it depends on how translations are shipped. For example, in .NET, you can ship translations as satellite assemblies and the original library doesn't need to change.
But if you were to package translations with the library and re-issue the library, then yes, the PATCH would have to change.
@salcode commented on GitHub (Nov 30, 2015):
Thank you both for your input. I'm hearing,
Update the patch version for bundled translations and do not modify the version for translations that are independent entities and can be distributed separately.
This is an excellent guideline I will keep in mind in the future.
@KyNorthstar commented on GitHub (Sep 21, 2019):
I would say that translations change the way the user uses the app in a backwards-compatible way, so it would be a MAJOR or MINOR release, never PATCH
@wizzwizz4 commented on GitHub (Sep 21, 2019):
It wouldn't be major, since it's backwards-compatible.
I suppose it depends on whether the UI is part of the interface.
@KyNorthstar commented on GitHub (Sep 30, 2019):
So MINOR, then, it's agreed. I should expect strong universal support that the User Interface is part of the interface.
@wizzwizz4 commented on GitHub (Sep 30, 2019):
Well, it depends which interfaces you're SemVering. If, for instance, you're just localising the failed-assertion error messages of your API based on environment variables, no production code is going to run into that new translation. If you're localising the GUI but SemVer is for the command-line interface, again, that's not an interface change.
@wizzwizz4 commented on GitHub (Sep 30, 2019):
Less obviously, if you translate all of your error messages but those were never defined as part of the interface, that's not an interface change either – it's basically the same as changing the calling convention on an unexposed internal method.
@KyNorthstar commented on GitHub (Oct 27, 2019):
@wizzwizz4 Assuming the user-facing application has a separate version number from the developer-facing API, then the user-facing version number should increment at least its MINOR if its translation changes.
I wouldn't expect the developer-facing code to be a part of the translation, so its PATCH would be updated.
If your product entangles these versions, then go with the most significant change of the two.
@wizzwizz4 commented on GitHub (Oct 28, 2019):
@BenLeggiero I agree, but if you're entangling them you're probably not in a position to use SemVer in the first place (correlation, not causation, mind).