https://bugzilla.mozilla.org/show_bug.cgi?id=412296#c1 seems to say that that one shouldn't go in 1.8. Any reason it's still blocking this?

Dirkjan, my bug 412296 comment 1 was intended to agree that the fix is important to make for js1.8src. Waldo, you have time for that bug? /be

Ah, sorry about my misunderstanding. I understand Waldo has gone hiking for at least a few weeks, so he won't be around anytime soon.

moving the dependencies to bug 380236 which is where the code changes for js1.8 should be tracked.

I don't get it -- what's the point of this bug, then? In the past, js1.N has been the bug alias for tracking language definition work, including implementation, and js1.Nsrc is for the source release, including any non-language, API and/or embedding fixes. That still seems like a useful distinction. /be

reverting.

Assigning to bc. Let's go ahead and do this. I can release-note bug 349263, bug 419537, and bug 384758. The first two are only problems if you use JS_THREADSAFE *and* share objects among threads (specifically arrays, iterators, and generators; if you only share strings you're ok). The third is a parser bug that we can live with. IIUC 1.8 should ship out of CVS, the Mozilla 1.9.0 branch. So we need to bump JS_GetImplementationVersion there. Anything else?

The nmake js.mak doesn't build with VC6 or VC8.

Heh, points for noticing that. I thought we cvs rm'd it! Please just omit it from the distribution and I'll release-note its demise as well. It is long gone from hg. This is not a big deal. I honestly don't know if js.mak was working two years ago. I think people building SpiderMonkey on Windows pretty much just point-and-click a new library project, drop in all the files, set a few project options, and hit F5. The bloody-minded few (if any) still using nmake at this date can fend for themselves.

Release notes are up at: https://developer.mozilla.org/En/SpiderMonkey/1.8 I have nothing to add to those other than the download URL.

Comment on attachment 362561 [details] [diff] [review] patch rev JS_GetImplementationVersion Yep, works for me.

jorendorff noticed that all previous releases used pre-release. This patch uses that convention and also includes the removal of js.mak the obsolete NMAKE make file.

Comment on attachment 362567 [details] [diff] [review] patch v2 - rev JS_GetImplementationVersion and remove js.mak That version-string works just as well for me. Approvers: This doesn't have to be in 1.9.0.7 specifically. bc correct me if I'm wrong-- we really just want this checked in so we can tag and release a SpiderMonkey 1.8 source distribution.

Um, to clarify, I don't know whether approval1.9.0.7? or approval1.9.0.8? is the appropriate flag to request. We just want it in as soon as possible. The changes are barely-part-of-the-build (js.mak was never part of the build; JS_GetImplementationVersion is never called, except in some unused code in xpcshell).

Comment on attachment 362567 [details] [diff] [review] patch v2 - rev JS_GetImplementationVersion and remove js.mak We're frozen for 1.9.0.7, but we'll look at this when we start approvals for 1.9.0.8 this week.

Comment on attachment 362567 [details] [diff] [review] patch v2 - rev JS_GetImplementationVersion and remove js.mak Approved for 1.9.0.8, a=dveditz for release-drivers Should the string change in jsapi.c say "pre-release 2" or was pre-release 1 never actually released?

never released.

attachment 362567 [details] [diff] [review] checked in to 1.9.0. Removing js.mak; /cvsroot/mozilla/js/src/js.mak,v <-- js.mak new revision: delete; previous revision: 3.13 done Checking in jsapi.c; /cvsroot/mozilla/js/src/jsapi.c,v <-- jsapi.c new revision: 3.447; previous revision: 3.446 done

An official release candidate is just waiting on (I think) two more bug fixes that are approved for the 1.9.0 tree but haven't yet landed.

This is now (I think) only waiting for bug 453955 to be landed in CVS.

(In reply to comment #21) > This is now (I think) only waiting for bug 453955 to be landed in CVS. Bug 453955 has just been landed in CVS.

ok, rc1 is done. tagged with JS_180_RC1 and pushed to http://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz

Regressions: * Arrays still are not thread-safe. * The RC has several other known thread-safety regressions (fixed in trunk and in mozilla-1.9.1 branch). (I tried to land those fixes on the 1.9 branch but they were too big. I couldn't get approval.) * I had an unconfirmed report that in this RC, Makefile.ref doesn't work on Windows. Of course these will be showstoppers for some embedders. But that is OK. Releasing SM 1.8 will not hurt those people. I think we should cut a final js-1.8.0.tar.gz from CVS and make this thing official. At this point I don't know who has time for another RC or any more bug fixes. Not me. "SM 1.8.1 source release" is bug 479473. Note that SM1.8.1 already has fixes for two of the three issues listed above.

These bugs are all part of a search I made for js bugs that are getting lost in transit: http://tinyurl.com/jsDeadEndBugs They all have a review+'ed, non-obsoleted patch and are not marked fixed-in-tracemonkey or checkin-needed but have not seen any activity in 300 days. Some of these got lost simply because the assignee/patch provider never requested a checkin, or just because they were forgotten about.

js/spidermonkey 1.8.5 was released (see https://bugzilla.mozilla.org/show_bug.cgi?id=628723), i think this bug should be marked as resolved.

bug 628723 supercedes, wont-fix