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. > > 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] > <mailto:[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] <mailto:[email protected]> >> http://groups.google.com/group/v8-users > > -- > 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
