How should be versioned language bindings/wrappers?
Original api:
May use semver, or not.
May be updated in 3 ways (major, minor, patch).
Binding/wrapper:
Possess their own api and changes (even if original api still same).
Depended on original api, and follows for its updates.
Just merging both changes in single x.y.z causes disorientation, which grows with time.
Originally created by @Playermet on GitHub (Feb 13, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/352
How should be versioned language bindings/wrappers?
Original api:
1) May use semver, or not.
2) May be updated in 3 ways (major, minor, patch).
Binding/wrapper:
1) Possess their own api and changes (even if original api still same).
2) Depended on original api, and follows for its updates.
Just merging both changes in single x.y.z causes disorientation, which grows with time.
@Playermet, what is meant by "binding/wrapper". I am not following your scenario.
<!-- gh-comment-id:348359818 -->
@jwdonahue commented on GitHub (Nov 30, 2017):
@Playermet, what is meant by "binding/wrapper". I am not following your scenario.
This is an old issue, but I have the same (or a similar) question.
Imagine I have a C library called Foo, and I make a JS binding called FooJS, both using semver
I would like the version of Foo.js to reflect the semver of Foo, so that FooJS v2.1.2 would be a binding to Foo v2.1.2 (this is option 2 for the binding as outlined above). This has lots of advantages - clarity for the end user, guarantee that the binding updates following the core lib's guarantees for semver, etc.
However, assuming the binding has a few non-trivial details, if I need to fix the binding while maintaining the core lib's version I'm not sure how to proceed. If I use FooJS v.2.1.2-1 this is considered an unstable pre-release version by most clients. If I bump the patch version on FooJS I am out of sync with the core Foo library, a state that gets even worse on the next Foo patch bump.
How does semver handle this situation?
<!-- gh-comment-id:367125680 -->
@nrabinowitz commented on GitHub (Feb 20, 2018):
This is an old issue, but I have the same (or a similar) question.
* Imagine I have a C library called `Foo`, and I make a JS binding called `FooJS`, both using semver
* I would like the version of `Foo.js` to reflect the semver of Foo, so that `FooJS v2.1.2` would be a binding to `Foo v2.1.2` (this is option 2 for the binding as outlined above). This has lots of advantages - clarity for the end user, guarantee that the binding updates following the core lib's guarantees for semver, etc.
* However, assuming the binding has a few non-trivial details, if I need to fix the binding while maintaining the core lib's version I'm not sure how to proceed. If I use `FooJS v.2.1.2-1` this is considered an unstable pre-release version by most clients. If I bump the patch version on `FooJS` I am out of sync with the core `Foo` library, a state that gets even worse on the next `Foo` patch bump.
How does semver handle this situation?
Ok this is a package A depends on package B scenario and SemVer is not intended to provide dependency data. That said, you can always put +Foo.1.0.0 on the FooJS "binding" (adapter) if the packaging tool you are using supports the SemVer meta-tag. Most packaging tools have much better support for defining dependencies between SemVer compliant products, than by abusing the SemVer string itself however.
<!-- gh-comment-id:367787771 -->
@jwdonahue commented on GitHub (Feb 22, 2018):
Ok this is a package A depends on package B scenario and SemVer is not intended to provide dependency data. That said, you can always put +Foo.1.0.0 on the FooJS "binding" (adapter) if the packaging tool you are using supports the SemVer meta-tag. Most packaging tools have much better support for defining dependencies between SemVer compliant products, than by abusing the SemVer string itself however.
So basically, SemVer was not intended nor is it designed to solve this problem. You should use the SemVer string to designate the version of your interface or package. SemVer does not define how dependency graphs are documented. SemVer defines one kind of version string that would be part of the data at the nodes in the dependency graph. This is where packaging tools like npm and nuget come into play. They provide the means to define one node and all of its immediate neighbors, along with the tools to resolve the entire graph below that one node. As an engineer with 28 years of experience shipping products at every scale, I would advice that you should never pin the FooJS version to the Foo version. Such a decision will eventually cause you much grief.
<!-- gh-comment-id:367791981 -->
@jwdonahue commented on GitHub (Feb 22, 2018):
So basically, SemVer was not intended nor is it designed to solve this problem. You should use the SemVer string to designate the version of your interface or package. SemVer does not define how dependency graphs are documented. SemVer defines one kind of version string that would be part of the data at the nodes in the dependency graph. This is where packaging tools like npm and nuget come into play. They provide the means to define one node and all of _its_ immediate neighbors, along with the tools to resolve the entire graph below that one node. As an engineer with 28 years of experience shipping products at every scale, I would advice that you should never pin the FooJS version to the Foo version. Such a decision will eventually cause you much grief.
@Playermet, unless you have further questions, please close this issue at your earliest possible convenience.
<!-- gh-comment-id:367793255 -->
@jwdonahue commented on GitHub (Feb 22, 2018):
@Playermet, unless you have further questions, please close this issue at your earliest possible convenience.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Playermet on GitHub (Feb 13, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/352
How should be versioned language bindings/wrappers?
Original api:
Binding/wrapper:
Just merging both changes in single x.y.z causes disorientation, which grows with time.
@jwdonahue commented on GitHub (Nov 30, 2017):
@Playermet, what is meant by "binding/wrapper". I am not following your scenario.
@nrabinowitz commented on GitHub (Feb 20, 2018):
This is an old issue, but I have the same (or a similar) question.
Foo, and I make a JS binding calledFooJS, both using semverFoo.jsto reflect the semver of Foo, so thatFooJS v2.1.2would be a binding toFoo v2.1.2(this is option 2 for the binding as outlined above). This has lots of advantages - clarity for the end user, guarantee that the binding updates following the core lib's guarantees for semver, etc.FooJS v.2.1.2-1this is considered an unstable pre-release version by most clients. If I bump the patch version onFooJSI am out of sync with the coreFoolibrary, a state that gets even worse on the nextFoopatch bump.How does semver handle this situation?
@jwdonahue commented on GitHub (Feb 22, 2018):
Ok this is a package A depends on package B scenario and SemVer is not intended to provide dependency data. That said, you can always put +Foo.1.0.0 on the FooJS "binding" (adapter) if the packaging tool you are using supports the SemVer meta-tag. Most packaging tools have much better support for defining dependencies between SemVer compliant products, than by abusing the SemVer string itself however.
@jwdonahue commented on GitHub (Feb 22, 2018):
So basically, SemVer was not intended nor is it designed to solve this problem. You should use the SemVer string to designate the version of your interface or package. SemVer does not define how dependency graphs are documented. SemVer defines one kind of version string that would be part of the data at the nodes in the dependency graph. This is where packaging tools like npm and nuget come into play. They provide the means to define one node and all of its immediate neighbors, along with the tools to resolve the entire graph below that one node. As an engineer with 28 years of experience shipping products at every scale, I would advice that you should never pin the FooJS version to the Foo version. Such a decision will eventually cause you much grief.
@jwdonahue commented on GitHub (Feb 22, 2018):
@Playermet, unless you have further questions, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Feb 27, 2018):
Related: #265