couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Increasing Spidermonkey version
Date Wed, 18 Nov 2009 21:50:48 GMT
On Wed, Nov 18, 2009 at 4:01 PM, Mikeal Rogers <> wrote:
>> Also, I'm hesitant to upgrade our minimum version requirement. The SM
>> release story is less than awesome. The only tarballs at [3] are for
>> 1.7 and 1.8.0 which is a weird limbo version between 1.7 and 1.8.1.
>> Not to mention its got a whacky build system that requires a specific
>> version of Autoconf. So, yeah, making the upgrades progressive would
>> be awesome.
> I'm a little worried about what effect minimum required versions vs. usable
> version will have on application portability.
> Newer versions of Spidermonkey, and other js interpreters if we plan on
> supporting them, support different versions of the javascript language which
> could lead to applications not being portable between different CouchDBs of
> the same CouchDB version but with differing js interpreters.
> -Mikeal

The same could be said of your Python view server vs. what's in
couchdb-python though, right? Or what happens when we move to a Py3K
view server? Not to mention if that language is even available. Or if
we go back to an old version that doesn't have _list/_show/_update.
We've also seen issues when running tests in Safari, or CouchDBX
running then from the WebKit environment.

I agree that its slightly more insidious that the same language view
server can introduce inconsistencies, but I don't think there's going
to be much we can do. I'm all for supporting newer versions of
Spidermonkey even with the new JSON parsing, but ATM there's no strong
reason to say "1.7 is too old" when it'll work just fine.

Though, I would be quite happy to throw large warnings in the
configure thing that say things like "You should upgrade because
client code may depend on newer versions of Library Foo" etc etc. As
well as perhaps exposing a 'user-agent' variable in the view servers
so that we can at least throw informative errors on why things fail.
Or maybe nifty, allow design documents to require a specific version
of the view server?

Paul Davis

View raw message