Repository navigation
V8 upgrades and what they mean for versioning #47
Description
Activity
We did actually discuss this in another thread. Basically, if we're on a weekly release cycle and v8 makes a breaking change that means that we bump the major version that week.
@mikeal I see, was this done in the node-forward repo? I've not kept up with every issue there. The initial release thread appeared to have just shrugged off the question with folks talking about rvagg/nan. And @indutny said that he "couldn't really say anything on this topic yet" which sounded to me like this wasn't something that was decided.
If you know it happened on node-forward or something, I can go looking there. But nothing on this repo appears to set that standard.
you know, I can't recall where the thread was, probably a good reason to just have this talk again :)
how i see it is, we're gonna follow semver now. if we take deps that changes backward or forward compatibility then we have to increment that semver number accordingly. staying on top of those changes will be a challenge but I think it's a worthy one.
-1. Wouldn't that cause dependency hell similar to peerDependencies?
Let's say npm package A is pure JS and package B uses native V8 API. All packages initially support io.js 1.0.0. Then assume that V8 API changes while the io.js JS API remain unchanged, the major version still bumps to 2.0.0. It is reasonable to require B to update their native code, but to A it is really minor version update of io.js and no update should be required. And if package maintainer of A do not update their package.json, a project that require both A and B would face dependency hell problem even when there really isn't one.
I thought the rationale behind semver is so that future npm packages can have dependency to certain version of io.js. That in turn allows io.js to make breaking changes in major version update while preventing outdated npm packages from being accidentally installed. The purpose of semver would be defeated if all pure JS npm packages ended up specifying that they can run on io.js version
*.*.*.I'd propose to have two or more version numbers come with every io.js release. We can have for example one version number for io.js JS APIs and another version number for V8 APIs. Then npm packages that contain native code can specify dependency to the V8 version in their package.json independent of the JS API version.
Taking this approach further, perhaps we can have separate versioning for different subsystems in io.js, such as libuv.js. Issue #9 already state that we'd like io.js to be split into smaller interdependent subprojects. It make sense to let these subsystems evolve independently and allow npm packages to have dependency to specific subsystems. Though in such case, the main version number of io.js would be mostly symbolic and is rarely needed for dependency management.
I get that v8 extensions are super powerful, but it's kind of lame that they are the only way to call into a C lib. Maybe it's just me, but I've always thought it was a really big hassle just to call an shared library compared to something like cgo or pinvoke in C#. Why can't there be a nice clean standard solution for shared C library invocation that ships with node and can be configured without writing a bunch of C++ code yourself? IMO, requiring everyone to learn the internals of v8 just to call a function on a C lib makes native extensions a lot more brittle than they need to be and is really painful.
Does it really have to be 100x more complicated than PInvoke?
[DllImport("msvcrt.dll")]
public static extern int puts([MarshalAs(UnmanagedType.LPStr)] string m);And cgo?
// #include <stdio.h>
import "C"C.puts("blah")
- Yes
- C++
- v1.0.0
On Mon, Dec 8, 2014, 07:19 Michael Caine notifications@github.com wrote:
Hello!
I am pleased to see your valuable contribution to this project. Would you
please mind answering a couple of questions to help me classify this
submission
and/or gather required information for the core team members?
Questions:- Issue-only Does this issue happen in core, or in some user-space
module from npm or other source? Please ensure that the test case that
reproduces this problem is not using any external dependencies. If the
error is not reproducible with just core modules - it is most likely not a
io.js problem. Expected: yes - Which part of core do you think it might be related to? One of:
debugger, http, assert, buffer, child_process, cluster, crypto, dgram, dns,
domain, events, fs, http, https, module, net, os, path, querystring,
readline, repl, smalloc, stream, timers, tls, url, util, vm, zlib, c++,
docs, other (label) - Which versions of io.js do you think are affected by this? One of:
v0.10, v0.12, v1.0.0 (label)
Please provide the answers in an ordered list like this:
- Answer for the first question
- Answer for the second question
- ...
Note that I am just a bot with a limited human-reply parsing abilities,
so please be very careful with numbers and don't skip the questions!In case of success I will say: ...summoning the core team devs!.
In case of validation problem I will say: Sorry, but something is not
right
here:.Truly yours,
Caine.
Responsibilities- indutny: crypto, tls, https, child_process, c++
- trevnorris: buffer, http, https, smalloc
- bnoordhuis: http, cluster, child_process, dgram
—
Reply to this email directly or view it on GitHub
#47 (comment).Oh, the bot reply is gone, replied via email and didn't see it got deleted
Is there any formal plan to keep iojs up-to-date with the latest (or latest-1) version of V8? The last upgrade seems to have been to 3.30.37, which is the latest version in the 3.30.x series. In case there is another 3.30.x release, would that translate to a patch version in iojs?
@ruimarinho that will depend on the nature of the V8 upgrades .. Google aren't exactly masters of versioning so I suspect decisions will be reactive rather than carefully planned on our part. If there is a breaking API change from V8 then that'll warrant a major version bump from io.js, if there are feature additions then likely just a minor bump.
Ok, fair enough. Is the plan to stick to
0.30.xon iojs1.0.0?41 remaining items
- added a commit that references this issue
on Feb 7, 2018 - added a commit that references this issue
on Feb 18, 2018 - added a commit that references this issue
on Oct 19, 2019 - added a commit that references this issue
on Nov 12, 2023 - added a commit that references this issue
on Nov 21, 2023
In the Initial Release issue @indutny says that the API shielding the users from V8 C++ API has been rejected. This lack of a shield + @mikeal's start of that thread here where it is stated that V8 will be merged as fast as possible when V8 releases brings up a very concrete problem.
The choices come down to the following if a shield is not developed for users to use. When V8 releases backwards incompatible changes to their C++ API:
Both of which have major consequences on the community who is trying to use iojs as a platform to build things on top of. The last solution, and one that makes even more sense in the world of faster releases and semver, is to protect the users and provide a stable API they can build against. The V8 API can still be there, but now there is a safe way for developers to write binary packages.
I understand that rvagg/nan exists and is even blessed. And perhaps that is the solution that core developers are alright with accepting and consider the V8 API not part of the API that iojs presents for its users. But that decision should be made official and communicated to the community that they are playing with fire if they touch the V8 API directly.