You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Paul Davis <pa...@gmail.com> on 2011/04/02 01:26:07 UTC

SpiderMonkey 1.8.5 upgrades

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] http://ftp.mozilla.org/pub/mozilla.org/js/

Re: SpiderMonkey 1.8.5 upgrades

Posted by Filipe David Manana <fd...@apache.org>.
I'm fine with trunk requiring 1.8.5+ and not being compatible with
previous releases.

On Sat, Apr 2, 2011 at 3:22 PM, Paul J. Davis
<pa...@gmail.com> wrote:
> Adam,
>
> I'm with Bob on this one. 1.1 and 1.0 are forked so they stay the same. This should only concern trunk.
>
> Also, just rewriting couchjs and letting configure choose for 1.2 might be doable.
>
> On Apr 2, 2011, at 6:09 AM, Robert Newson <ro...@gmail.com> wrote:
>
>> +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards.
>> Leave couchjs as is on 1.0.x and 1.1.x
>>
>> B.
>>
>>
>> On 2 April 2011 02:59, Adam Kocoloski <ko...@apache.org> wrote:
>>> On Apr 1, 2011, at 7:26 PM, 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] http://ftp.mozilla.org/pub/mozilla.org/js/
>>>
>>> Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it.  For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is.
>>>
>>> Trunk can drop support for SM 1.7.
>>>
>>> Adam
>>>
>>>
>



-- 
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Re: SpiderMonkey 1.8.5 upgrades

Posted by "Paul J. Davis" <pa...@gmail.com>.
Adam,

I'm with Bob on this one. 1.1 and 1.0 are forked so they stay the same. This should only concern trunk.

Also, just rewriting couchjs and letting configure choose for 1.2 might be doable. 

On Apr 2, 2011, at 6:09 AM, Robert Newson <ro...@gmail.com> wrote:

> +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards.
> Leave couchjs as is on 1.0.x and 1.1.x
> 
> B.
> 
> 
> On 2 April 2011 02:59, Adam Kocoloski <ko...@apache.org> wrote:
>> On Apr 1, 2011, at 7:26 PM, 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] http://ftp.mozilla.org/pub/mozilla.org/js/
>> 
>> Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it.  For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is.
>> 
>> Trunk can drop support for SM 1.7.
>> 
>> Adam
>> 
>> 

Re: SpiderMonkey 1.8.5 upgrades

Posted by Paul Davis <pa...@gmail.com>.
On Sat, Apr 2, 2011 at 7:28 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 2 April 2011 23:09, Robert Newson <ro...@gmail.com> wrote:
>> +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards.
>> Leave couchjs as is on 1.0.x and 1.1.x
>>
>> B.
>
> Makes sense;  +1.
>
> From a release perspective I would like to be clear why we are
> upgrading or not depending on the branch. Is it simply speed that
> folks are interested in, or is there new functionality that people
> need in 1.8.5?
>
> A+
> Dave
>

Mostly, because the last 'official' version of SM is 1.7 which we've
been required to support because there's nothing 'officially' released
since then. (1.7 was released in 2007).

Recently most people have either been using a 1.8.0rc1 tarball (which
is in a bit of a wonky position between 1.7 and 1.8.1+ where it has a
weird intermediary API) or a hash from the mozilla-central mercurial
repository.

Basically, we've been floating this upgrade because there was nothing
to latch onto. Now that 1.8.5 is out as a tarball, I reckon we'll see
most SM related projects making the jump pretty quickly. I know all of
my other projects will do so as well as soon as I find some free time.

Re: SpiderMonkey 1.8.5 upgrades

Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 2 April 2011 23:09, Robert Newson <ro...@gmail.com> wrote:
> +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards.
> Leave couchjs as is on 1.0.x and 1.1.x
>
> B.

Makes sense;  +1.

>From a release perspective I would like to be clear why we are
upgrading or not depending on the branch. Is it simply speed that
folks are interested in, or is there new functionality that people
need in 1.8.5?

A+
Dave

Re: SpiderMonkey 1.8.5 upgrades

Posted by Robert Newson <ro...@gmail.com>.
+1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards.
Leave couchjs as is on 1.0.x and 1.1.x

B.


On 2 April 2011 02:59, Adam Kocoloski <ko...@apache.org> wrote:
> On Apr 1, 2011, at 7:26 PM, 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] http://ftp.mozilla.org/pub/mozilla.org/js/
>
> Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it.  For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is.
>
> Trunk can drop support for SM 1.7.
>
> Adam
>
>

Re: SpiderMonkey 1.8.5 upgrades

Posted by Adam Kocoloski <ko...@apache.org>.
On Apr 1, 2011, at 7:26 PM, 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] http://ftp.mozilla.org/pub/mozilla.org/js/

Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it.  For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is.

Trunk can drop support for SM 1.7.

Adam


Re: SpiderMonkey 1.8.5 upgrades

Posted by Paul Davis <pa...@gmail.com>.
On Sun, Apr 3, 2011 at 1:03 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sat, Apr 2, 2011 at 1:26 AM, Paul Davis <pa...@gmail.com> 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] http://ftp.mozilla.org/pub/mozilla.org/js/
>>
> 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
release.

Re: SpiderMonkey 1.8.5 upgrades

Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Apr 2, 2011 at 1:26 AM, Paul Davis <pa...@gmail.com> 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] http://ftp.mozilla.org/pub/mozilla.org/js/
>
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

Re: SpiderMonkey 1.8.5 upgrades

Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Apr 2, 2011 at 1:26 AM, Paul Davis <pa...@gmail.com> 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] http://ftp.mozilla.org/pub/mozilla.org/js/
>

+1 to just keep support for 1.8.5 it make the code easier to read.

- benoit