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 On Sat, Feb 11, 2012 at 23:07, Jérémy Lal <[email protected]> wrote: > 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. > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
