Move version macros to public V8 header.

Move version macros to public V8 header.

Move the V8 version macros to the public v8.h file, so it can be used
by other projects for testing specific V8 versions at compile time.

Adjust tools to work on include/v8.h instead of src/version.cc. Make
sure tools/v8-info.sh falls back to src/version.cc when looking at
old versions.

Also add V8_CHECK_VERSION() and V8_VERSION_STRING macros for convenience.

BUG=v8:1844

[Benedikt Meurer, 2013-09-02 09:02:01]

PTAL

[Benedikt Meurer, 2013-09-02 09:02:50]

Hey Sven,
Please have a look.

CC'd Jakob for sanity checking of build system implications.

[Jakob Kummerow, 2013-09-02 11:00:47]

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 either (1) reasonable in terms of workload, (2) a
good idea in terms of security, or (3) officially encouraged/supported by the V8
team.

[Benedikt Meurer, 2013-09-02 11:02:26]

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 V8
> versions in embedding code is either (1) reasonable in terms of workload, (2)
a
> good idea in terms of security, or (3) officially encouraged/supported by the
V8
> team.

ACK.

[oliver.buchtala, 2013-09-02 20:43:50]

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 V8
> versions in embedding code is either (1) reasonable in terms of workload, (2)
a
> good idea in terms of security, or (3) officially encouraged/supported by the
V8
> team.

Ehhhm, come on, this is kind of ignorant. Sorry.

V8 is embeddable and is getting embedded.
There are not-so-mini projects such as node.js and also ours, SWIG, which have
to keep up with v8 API changes.
Considering the effort to have version macros up-to-date makes this denial hard
for me to understand.

Please consider to have version macros public.

[Sven Panne, 2013-09-03 07:44:22]

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 next few weeks/months, but
making transitions easier and making v8 a good team player in the Open Source
sense wouldn't hurt, anyway.

Another reason for this change is that it would make upgrading v8 in our
internal projects easier and less of a Herculean effort: With the version macros
in place, one could tentatively prepare embedding projects *before* updating v8,
and one could easily revert to the previous version when things go wrong. This
advantage alone should be enough to warrant this change.

In a nutshell: A strong +1 for this CL from my side.

[Benedikt Meurer, 2013-09-03 07:47:18]

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).

[Jakob Kummerow, 2013-09-03 09:36:56]

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.

[Sven Panne, 2013-09-03 10:01:32]

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, clearly stating
that the numbers are purely "marketing numbers" with no semantics whatsoever,
especially that they don't guarantee any kind of ABI interface like the usual
major.minor.patchlevel scheme. In addition, we can add a note encouraging people
to upgrade and stating that we only care about the latest version regarding bug
fixes.

[Jakob Kummerow, 2013-09-03 10:29:53]

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 a push manually [only takes 1-2
hours].)