Hey Sven,
Please have a look.
CC'd Jakob for sanity checking of build system implications.
https://codereview.chromium.org/23723003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Gr
High-level comment:
I'm not convinced that we want this change. Given the rate at which the V8
API
changes, and the rate at which new branches are created and old branches
become
unsupported, I'm hesitant to create the appearance that supporting several
V8
versions in embedding code is eithe
On 2013/09/02 11:00:47, Jakob wrote:
High-level comment:
I'm not convinced that we want this change. Given the rate at which the
V8 API
changes, and the rate at which new branches are created and old branches
become
unsupported, I'm hesitant to create the appearance that supporting
several
I would support this change, too, for various reasons. In the past, the
external
API changed only very slowly, so it was easy for embedders to follow.
Recently,
the rate of change went up dramatically, so the embedder's life got much
harder.
The external API will hopefully stabilize in the n
For the record: +1 from my side as well (my point of view is that Open
Source is
more than just uploading source code somewhere).
https://codereview.chromium.org/23723003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message bec
This has nothing to do with being ignorant, Open Source, or a good team
player.
My point is that when these macros exist, projects will inevitably use them
to
effectively pin themselves against outdated V8 versions, especially in
scenarios
where they don't bundle/control the V8 version they
LGTM. There are very good reasons for *not* closely tracking any dependency
in a
complex project (=> the dreaded diamond dependency problem), some missing
bug
fixes are the least problem one usually has under these circumstances.
Nevertheless, we should add a comment above the version macros,
Not so fast!
Low-level comment: This will break merge-to-branch.sh for merging patches
from a
branch with the change to one without. That's not acceptable, please don't
land
until you have a fix. (It'll also break push-to-trunk.sh, but there it's a
one-off, which you can work around by doing
