soname and upstream-tracker

[Jérémy Lal]

Hi,
right now SONAME is not set by v8 upstream authors.
I understand that :

1. they encourage people to embed v8, not distribute it as a shared lib,
2. it requires expertise to keep ABI compatibility in a C++ lib.

Let me address those points :

1. Distributions like debian are pushing forward the use of shared libs,
for maintenance and security reasons. A fix to libv8 is done once and
in only one place. It doesn't have to be done in each embedded copy of the lib.

2. i don't have that expertise. Maybe only one guy in the world has it
(the kde libs are given in example most of the time).
So i end up having SONAME = VERSION, which is a shame from a distribution
point f view, since it requires recompiling each software depending
on v8 as a shared lib, even for patch level version bumps.
Because of that, pushing latest versions (to debian in my case) is often delayed.

However, with a tool like :
http://upstream-tracker.org/versions/v8.html
which is using abi-compliance-checker (which i really don't know the quality),
i wonder if it could be used by v8 authors to define a SONAME that changes
only when ABI breakage is detected.

Trying to keep ABI compatibility across a given branch, say,
from version 3.6.0 to 3.6.6.20, the soname stays at 3.6, is probably not
what is wanted either, because it would put to much constraints to
the possible changes within a branch.
But having a defined SONAME that changes less often than at every tagged version,
would be a real bonus for us, package maintainers, and for you, as newer compatible
versions would be adopted faster.

Regards,
Jérémy.

[Jakob Kummerow]

Hi Jérémy,

I've been meaning to get back to you about this.

First off, I'm aware of the issues you raise, and I'm sympathetic to your points. However, I'm afraid I can't promise you any changes, because unfortunately making life easier for Linux distributions to include V8 as a system library is not very high on the team's list of priorities. That is not to say that we don't encourage you to do precisely this, it's just that our resources are finite. If we decided to supply official SONAMEs, we would have to test them and make sure they are actually correct, which is non-trivial for a C++ library, as far as I know.

We are an open source project though -- maybe you (or someone else from the community) wants to take up maintainership of a (semi-)officially provided SONAME?

As a first step in this direction, maybe you could, as a packager, refer to http://upstream-tracker.org to define your own SONAMEs according to reported API/ABI breakage. If that works out well, you could contribute your additions upstream, and maybe we could even automate the system eventually.

It may also help you to understand the way V8 version numbers are chosen. Contrary to most (?) other libraries, we don't increment the version number according to changes in interface or functionality. Instead, we pick them based on date:

• Day-to-day development happens on our bleeding_edge branch. Commits don't get version numbers, just (SVN/git) revision numbers.
• When we push the changes from the bleeding_edge branch to trunk, which usually happens several times a week, we bump the third component of the version, e.g. 3.8.4 -> 3.8.5.
• When we create a branch for a new Chromium milestone, we freeze the first three components of the version number for that branch, and bump the second component for trunk (and bleeding_edge). E.g. 3.8.9 became the 3.8 branch, and trunk development continued with 3.9.0. It is *not* the case that there would be particularly many changes at this time. The expected difference between 3.8.8 and 3.8.9 is just as big as between 3.8.9 and 3.9.0. (Contrary to what e.g. the Linux kernel does, where there is a huge amount of changes before an -rc1 version, and very little change between, say, -rc8 and -rc9.)
• When we backport an important fix from trunk to a branch, we bump the fourth component. E.g. the first patch to the 3.8 branch would create 3.8.9.1. There is typically no or very little API/ABI change within an x.y.z.* series, but we make no guarantees about that.

The upshot of all this is that downstream projects that care about stability should use our branches, not our trunk. That means: when you see a four-component version number being tagged, that'd be an interesting candidate for a distro package. You could even wait a little, e.g. when you see 3.8.9.1 being tagged, you wait two or three weeks and then take 3.8.9.<highest-number-that-there-is-by-then> as your package. This way, you'd have one new version roughly every six weeks -- that should be quite acceptable, I think. And you could safely assume that there has been enough change since the last branch (e.g., from 3.7.12.x to 3.8.9.y) to warrant a new SONAME ;-)

If you follow additional patches to the branch (e.g., you packaged 3.8.9.6, and then we tag 3.8.9.7), that would of course increase the number of new packages, but as described above, there would usually be very little API change between these bugfix releases, and you could use a tool to determine if you need to bump the SONAME or not.

If you look at the V8 versions included in stable releases of Chrome, you will find roughly the same pattern (V8 branches only go on the Chrome stable channel ~6 weeks after they've been branched off of V8 trunk).

There is no reason for a distro to package V8 v3.9.0 "because it's the new 3.9 version". 

Hope this helps,

Jakob

> --
> v8-users mailing list
> v8-u...@googlegroups.com
> http://groups.google.com/group/v8-users

[Jérémy Lal]

Thank you for your answer and explanation.

What you suggest is partly what we already do in debian : package 3.7.12.22
just got in because chromium 17 use it (I have not even started packaging branch 3.8).

I like the idea of giving a new soname to each branch, considering v8 is "released"
and so has a final soname only when the branch has matured enough.
The table given by upstream-tracker conforts this.

I'll open an issue if i come up with some automated soname check.

Regards,
J�r�my.

On 21/02/2012 15:11, Jakob Kummerow wrote:
> Hi J�r�my,

>
> I've been meaning to get back to you about this.
>
> First off, I'm aware of the issues you raise, and I'm sympathetic to your points. However, I'm afraid I can't promise you any changes, because unfortunately making life easier for Linux distributions to include V8 as a system library is not very high on the team's list of priorities. That is not to say that we don't encourage you to do precisely this, it's just that our resources are finite. If we decided to supply official SONAMEs, we would have to test them and make sure they are actually correct, which is non-trivial for a C++ library, as far as I know.
>
> We are an open source project though -- maybe you (or someone else from the community) wants to take up maintainership of a (semi-)officially provided SONAME?
>
> As a first step in this direction, maybe you could, as a packager, refer to http://upstream-tracker.org to define your own SONAMEs according to reported API/ABI breakage. If that works out well, you could contribute your additions upstream, and maybe we could even automate the system eventually.
>
> It may also help you to understand the way V8 version numbers are chosen. Contrary to most (?) other libraries, we don't increment the version number according to changes in interface or functionality. Instead, we pick them based on date:
>

> * Day-to-day development happens on our bleeding_edge branch. Commits don't get version numbers, just (SVN/git) revision numbers.
> * When we push the changes from the bleeding_edge branch to trunk, which usually happens several times a week, we bump the third component of the version, e.g. 3.8.4 -> 3.8.5.
> * When we create a branch for a new Chromium milestone, we freeze the first three components of the version number for that branch, and bump the second component for trunk (and bleeding_edge). E.g. 3.8.9 became the 3.8 branch, and trunk development continued with 3.9.0. It is *not* the case that there would be particularly many changes at this time. The expected difference between 3.8.8 and 3.8.9 is just as big as between 3.8.9 and 3.9.0. (Contrary to what e.g. the Linux kernel does, where there is a huge amount of changes before an -rc1 version, and very little change between, say, -rc8 and -rc9.)
> * When we backport an important fix from trunk to a branch, we bump the fourth component. E.g. the first patch to the 3.8 branch would create 3.8.9.1. There is typically no or very little API/ABI change within an x.y.z.* series, but we make no guarantees about that.

>> J�r�my.
>>
>> --
>> v8-users mailing list
>> v8-u...@googlegroups.com <mailto:v8-u...@googlegroups.com>
>> http://groups.google.com/group/v8-users

[Paweł Hajdan, Jr.]

On Tue, Feb 21, 2012 at 15:11, Jakob Kummerow <jkum...@chromium.org> wrote:

However, I'm afraid I can't promise you any changes, because unfortunately making life easier for Linux distributions to include V8 as a system library is not very high on the team's list of priorities.

This translates directly to the adoption of V8 (there are already known projects using it, not just Chromium), and isn't it one of the project goals?

Note that often you don't need to do a lot. For example, since a shared library Linux configuration has been added to V8 buildbot, I've seen no test breakage when packaging, and that's very helpful and appreciated.

 

That is not to say that we don't encourage you to do precisely this, it's just that our resources are finite. If we decided to supply official SONAMEs, we would have to test them and make sure they are actually correct, which is non-trivial for a C++ library, as far as I know.

First you'd need some kind of V8 releases. Currently what e.g. I take is what's included in Chromium. However, V8 should really gets its own releases announced on V8 pages (feel free to make them repeat what's included in Chromium, but more "independence" should help).