Add a note about transitive dependencies on JVM #414
Conversation
|
FYI @jwdonahue |
| @@ -286,6 +286,19 @@ modification depends on whether you updated your dependencies in order to fix | |||
| a bug or introduce new functionality. I would usually expect additional code | |||
| for the latter instance, in which case it's obviously a minor level increment. | |||
|
|
|||
| #### Special note for JVM or similar environments | |||
There was a problem hiding this comment.
That makes it sound like it's a special case when it's actually the norm. It's problematic even in environments that do allow multiple versions of the same library.
I think the real issue is that the previous FAQ is misleading.
For example, let's take a really simple API:
frobnicate: Widget -> Result
Now upgrade the widget library to an incompatible version. (Eg: 1.0.0 to 2.0.0) Now the API is:
frobnicate: Widget -> Result
No change, right? Except this API is incompatible with the previous API because it now requires a v2 Widget instead of a v1 Widget.
Of course anyone reading the previous FAQ carefully enough would realize that when the version of a library is implicitly part of the public API, then changing it is changing the public API despite diff not showing a difference. Many people appear to not read it carefully enough.
And also of course, in environments like the JVM that only allow a single version of a library, even when a library is used "purely internally" and not even mentioned in the public API, it is still part of the undocumented public API in that it precludes the use of a different version of that library.
There was a problem hiding this comment.
@aij, you are getting interface and package mixed up. An interface never has any implementation issues to consider.
There was a problem hiding this comment.
@jwdonahue Could you elaborate? I didn't think I was talking about packages at all.
I was talking about non-textual (contextual?) interface changes. An interface can be changed in an incompatible way even without any textual changes to it's definition, by merely changing the context. For the above example, if the Widget interface is changed incompatibly, it changes the meaning of Widget -> Result, even though that text itself is not changed.
The reason I put quotes around "purely internally", is because a lot of environments don't support making use/nonuse of a library into an implementation detail. It necessarily becomes part of the public interface in environments that can't/don't link in multiple copies of the same library. (JVM, *nix shared libraries, most (all?) C static libraries, OCaml, Python, etc)
There was a problem hiding this comment.
@aij, I must have misread something. I thought you were talking about interfaces when in fact you were talking about packages/libraries.
semver.md
Outdated
| @@ -286,6 +286,19 @@ modification depends on whether you updated your dependencies in order to fix | |||
| a bug or introduce new functionality. I would usually expect additional code | |||
| for the latter instance, in which case it's obviously a minor level increment. | |||
|
|
|||
| #### Special note for JVM or similar environments | |||
|
|
|||
| In JVM or other environments where only one version of a library could | |||
There was a problem hiding this comment.
Just remove "JVM or other", and I think it works.. The SemVer spec implicitly covers what this FAQ change makes explicit.
semver.md
Outdated
|
|
||
| In JVM or other environments where only one version of a library could | ||
| be present in a running system, the transitive dependencies effectively become | ||
| part of the public API and thus the version of the user library SHOULD be |
There was a problem hiding this comment.
I would prefer "Interface" over "API", but that issue is still open to some debate.
|
I've created a PR to |
|
I am currently under the impression that all the active work on the spec is happening over on semver.org. Hence the extreme difference in the depth of the backlogged PR's. Somebody (@haacked) might come along and confirm or deny whether this impression is warranted. |
|
@jwdonahue There is an opposite opinion - semver/semver.org#180 (comment). Could you discuss with @haacked ? |
|
@Primetalk, @haacked is the authority on this, my apologies for any confusion. |
|
What is next step to proceed and have PR merged ? is there any issue/clarification still pending? |
|
@jwdonahue could you clarify what are the remaining obstacles? |
|
@Primetalk, Sorry, life has intervened and each time I looked at this, I didn't have time to recover enough context. I may be among the most active on this projects issues section, but I have little influence over what is merged. I think that any accepted changes will necessitate a good deal of work on translations, so this PR may languish until sufficient resources are available. @haacked, this looks like a patch level addition to the spec that clarifies what the rules actually mean in an important real-world scenario. It answers a common enough question here and on StackOverflow that I have come to believe it should be clarified in the FAQ. I think a strict interpretation of the spec, does imply the transitive relationship between version changes across dependent libraries referenced in a package, but it seems to be open for interpretation. We should consider taking this change or something like it. |
|
@jwdonahue, which translations are mandatory ? I see 22 translations of official page. Who is supposed to provide such translations ? is up to author of Pull Request to provide all this stuff ? before to start translating I guess final confirmation of current English version is needed, not ? |
|
Don't worry about it. Actual work here seems to happen in cycles. As far as I know, @haacked is the only one who can accept PR's and he's a busy guy with a life beyond SemVer. |
|
@jwdonahue The PR with the changes you requested in #414 (review) has been closed by @haacked. See comment: semver/semver.org#180 (comment) |
|
@Primetalk, Looks likes we have a PR in both semver/semver.org and semver/sember. Guess @haacked wants to get this one resolved first. I've never been clear on exactly how changes are supposed to flow into the spec. |
|
Closing & re-opening to trigger CI |
|
@Primetalk Thanks for contribution 👍 |
alexandrtovmach
added
extend
|
@alexandrtovmach - fixed. |
|
This note should mention that for JVM a developer could use a package relocation tool, like shadow in order to avoid all this. |
|
Also, the wording is too broad. It's not JVM environment, it's just the default class loader. |
Closes #341