On Tue, Feb 21, 2012 at 15:11, Jakob Kummerow <[email protected]>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). > 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 > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
