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 run/compile against.
That's
irresponsible and dangerous, and we should not encourage it or make it
easier to
do.
Of course *not* having version macros doesn't *force* them to update more
frequently either, but that's beside the point. *Having* version macros
creates
the impression of supporting such risky and brittle practices.
Yes, embedders have to keep up with API changes. But they have to do that
either
way, and version macros don't make it easier. I think node.js's approach
works
fine: they track V8; every Node version (whether it's trunk or release) is
built
to work with a specific V8 version. There's no need for version macros in
this
scenario.
Side note: when you embed a branched V8 version that's older than a week or
two
(which you should!), you are pretty much guaranteed that nothing will break
during the life cycle of this branch. Maybe this whole issue is based on the
misunderstanding that tracking V8 trunk would be a good idea for most
embedders?
So, I'm still opposed to this change, but if you want to overrule me, go
ahead,
I won't veto it.
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 Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
