couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: SpiderMonkey 1.8.5 upgrades
Date Sun, 03 Apr 2011 18:25:23 GMT
On Sun, Apr 3, 2011 at 1:03 PM, Benoit Chesneau <> wrote:
> On Sat, Apr 2, 2011 at 1:26 AM, Paul Davis <> wrote:
>> Hey,
>> Mozilla released a SM 1.8.5 source distribution this morning [1].
>> We've been getting requests from various places to upgrade our couchjs
>> to use this newer version for a couple weeks and now that its
>> available, there's no better time to act.
>> As can be expected, this new SpiderMonkey has a fairly significant API
>> change from what we've been using in couchjs. Up until now we've been
>> able to get away with supporting 1.7 and the 1.8.0rc1 tarballs without
>> much hassle. The new API makes this much more difficult. Chris C
>> Coulson from Ubuntu has been working on a patch that'll allow us to
>> work with 1.8.5 and (IIRC) should work with the 1.8.0rc1 but it
>> includes some extra gnarly ifdef magic to make things work.
>> So my question is what versions of SM should we support? I would
>> probably vote to drop everything in favor of 1.8.5 and no longer
>> support the older APIs. There is a possibility of just having two
>> versions of couchjs that we choose at compile time. But from what I've
>> heard and seen, we're basically not going to be able to have a single
>> compile time ifdef decision on versions without some super screw code.
>> Thoughts?
>> [1]
> Do we need a vote for such things ? For now the only reason I see to
> keep 1.7 compatibility is the lack of packages in linux distributions
> and BSDs. And itt will take some times to have since maintainers need
> to test these changes with different platforms and software using
> them. For example, this change is actually discussed for OPenBSD, but
> there are some problem to have it working on diff platforms which may
> block the release.
> So maybe for 1.1 we could keep the compatibility with 1.7 and see the
> status of packages on next release ?
> - benoƮt

Just to reiterate, I'm on suggesting bumping the requirement for
trunk. 1.1 has already been branched and is just waiting for something
to fall from the sky before it gets released. 1.2 won't be out for
quite some time which should hopefully let distros pull in the new SM

View raw message