You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Producing Spidermonkey JavaScript Releases

This document details how to produce a new Spidermonkey release newversion with release tag JS_newversion.

Prerequisites

You must either perform these procedures on a Unix/Linux box or under Cygwin (Windows) with Unix line endings.
Ask Brendan if there are any temporary fixes in js/src that would be inappropriate to release (e.g. DOM hacks, etc.)
You should plan on updating JS_GetImplementationVersion() in jsapi.c prior to any code freezes which may affect your ability to check in changes into CVS.

Document Conventions

All examples are written as if user foo was working on his local machine bar.com.

black text is normal prompt

# lines beginning with # are inline comments describing the procedure

blue text is user input.

underlined blue text is a variable value which must be substituted.

# the login name, machine name and directory path for each command
# are displayed as the prompt:

foo@bar.com:path
$

# commands are split into shorter segments using \
# to continue the command across line boundaries. 
# this helps keep the width of the page manageable.
#
foo@bar.com:path
$this is a very long \
command that has been split into shorter lines \
for presentation purposes

Directory locations

This discussion assumes that files are placed in your home directory ~ underneath the SpiderMonkey sub-directory.

foo@bar.com:~
$mkdir SpiderMonkey

foo@bar.com:~
$cd SpiderMonkey

foo@bar.com:~/SpiderMonkey
$

Set up CVS to use ssh

foo@bar.com:~/SpiderMonkey
$export CVS_RSH=ssh

Checkout Release Notes

You will need to add new release notes for the release to http://www.mozilla.org/js/spidermonkey/release-notes/. See CVS Access to the Website Tree for information about getting an account.

Checkout the Spidermonkey release notes

foo@bar.com:~/SpiderMonkey
$cvs -z3 -d ":ext:foo%bar.com@cvs-www.mozilla.org:/cvsroot" \
co -d release-notes mozilla-org/html/js/spidermonkey/release-notes

foo@bar.com:~/SpiderMonkey
$

Obtain the previous release

If you do not already have the source for the previous release, download the tarball ftp://ftp.mozilla.org/pub/mozilla.org/js/js-oldversion.tar.gz of the previous release JS_oldversion from ftp://ftp.mozilla.org/pub/mozilla.org/js/

foo@bar.com:~/SpiderMonkey
$mkdir oldversion

foo@bar.com:~/SpiderMonkey
$cd oldversion

foo@bar.com:~/SpiderMonkey/oldversion
$wget ftp://ftp.mozilla.org/pub/mozilla.org/js/js-oldversion.tar.gz

foo@bar.com:~/SpiderMonkey/oldversion/
$tar -zxvf js-oldversion.tar.gz

foo@bar.com:~/SpiderMonkey/js_oldversion
$cd ~/SpiderMonkey

foo@bar.com:~/SpiderMonkey
$

Checkout the appropriate version of SpiderMonkey.

Create the directory where your working copies will be located.

foo@bar.com:~/SpiderMonkey
$mkdir newversion
  
foo@bar.com:~/SpiderMonkey
$cd ~/SpiderMonkey/newversion

foo@bar ~/SpiderMonkey/newversion
$mkdir js

foo@bar ~/SpiderMonkey/newversion
$cd js

foo@bar ~/SpiderMonkey/newversion/js
$

Releasing from the trunk

foo@bar ~/SpiderMonkey/newversion/js
$cvs -z3 -q -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
   co -d src mozilla/js/src

foo@bar ~/SpiderMonkey/newversion/js
$cvs -z3 -q -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
   co -d jsd mozilla/js/jsd

foo@bar ~/SpiderMonkey/newversion/js
$cd src

#
# xpconnect is not part of SpiderMonkey, so remove it.
#
foo@bar ~/SpiderMonkey/newversion/js/src
$rm -fR xpconnect/

foo@bar ~/SpiderMonkey/newversion/js/src
$cvs -z3 -q -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
   update -d config liveconnect/config perlconnect editline

foo@bar ~/SpiderMonkey/newversion/js/src
$

Releasing from a Tag or Branch

foo@bar ~/SpiderMonkey/newversion/js
$cvs -z3 -q -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
   co -d src -r TAG mozilla/js/src

foo@bar ~/SpiderMonkey/newversion/js
$cvs -z3 -q -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
   co -d jsd -r TAG mozilla/js/jsd

foo@bar ~/SpiderMonkey/newversion/js
$cd src

#
# xpconnect is not part of SpiderMonkey, so remove it.
#
foo@bar ~/SpiderMonkey/newversion/js/src
$rm -fR xpconnect/

#
# the following directories only exist on the trunk.
# so you must use update -A
#
foo@bar ~/SpiderMonkey/newversion/js/src
$cvs -z3 -q -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
   update -A -d config liveconnect/config perlconnect editline

foo@bar ~/SpiderMonkey/newversion/js/src
$

Build the debug JS shell

If you are building under Windows with MSVC, you must build from a DOS command shell. The following commands will work both under Unix/Linux and Windows.

Set up your build environment as you would when building debug Seamonkey or debug Mozilla Firefox and build the debug js shell.

foo@bar.com:~/SpiderMonkey/newversion/js/src
$make -f Makefile.ref

Build the optimized JS shell

Set up your build environment as you would when building optimized Seamonkey or optimized Mozilla Firefox and build the optimized js shell.

foo@bar.com:~/SpiderMonkey/newversion/js/src/
$make -f Makefile.ref BUILD_OPT=1

check the JS version by doing ./js --help

run the JS testsuite on it in and compare the failures to those listed in the release notes. Remove any bugs listed as fixed which do not pass.

Remove the object directories containing the compiled js shell.

foo@bar.com:~/SpiderMonkey/newversion/js/src/
$rm -fR *.OBJ

Update JS_GetImplementationVersion()

If you are releasing SpiderMonkey from the trunk or a branch, you should update JS_GetImplementationVersion() in jsapi.c to the appropriate date and version of the release and check this change into the trunk or the appropriate branch before tagging. File a new bug for the version change in Core:JavaScript Engine, get approvals, etc and check in the change.

If you are releasing SpiderMonkey from a previous Firefox release tag and did not already update JS_GetImplementationVersion(), you should just live with that fact.

foo@bar.com:~/SpiderMonkey/newversion/js/src
$emacs jsapi.c

foo@bar.com:~/SpiderMonkey/newversion/js/src
$cvs -z3 -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
ci -m "bug xxxxx, updating JS_GetImplementationVersion() for SpiderMonkey version" jsapi.c

Determine the Spidermonkey Release Tags

Each release is tagged in CVS using a release tag of the form JS_version. Release candidates may have _RCn appended to version to indicate the n^th release candidate.

To check previous SpiderMonkey release tags:

foo@bar.com:~/SpiderMonkey/newversion/js/src
$cvs -z3 -q -d ":pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot" \
   log js.c | egrep JS_[0-9]+\(_RC[0-9a-z]+\)?:
        JS_150: 3.80
        JS_150_RC6a: 3.77
        JS_150_RC6: 3.76
        JS_150_RC5a: 3.65
        JS_150_RC5: 3.61
        JS_150_RC4a: 3.57
        JS_150_RC4: 3.53
        JS_150_RC3a: 3.46
        JS_150_RC3: 3.44.0.4
        JS_150_RC2: 3.29.0.4
        JS_150_RC1: 3.25

foo@bar.com:~/SpiderMonkey/newversion/js/src
$

Determine the release tag of the previous release, pick the next release tag and update this document (~/SpiderMonkey/release-notes/spidermonkey-releases.html).

Spidermonkey Releases
Release Tag	Date
JS_160	2006-11-21
JS_150	2005-09-28
JS_150_RC6a	2004-06-09
JS_150_RC6	2004-01-27
JS_150_RC5a	2003-05-29
JS_150_RC5	2003-01-10
JS_150_RC4a	2002-03-21
JS_150_RC4	2002-01-01
JS_150_RC3a	2001-05-11
JS_150_RC3	2001-03-07
JS_150_RC2	2000-08-10
JS_150_RC1	2000-03-03

Update the Change Log for this release.

The Change Log is supposed to contain a list of all bugs fixes in SpiderMonkey since the last release. There are two major sources for determining the bugs that have been fixed.

Bugzilla
Do a Bugzilla query on all bugs with:

Product Core, Component JavaScript Engine, Where Resolution changed to FIXED between last release date to (the release date; hard-coded) [DON'T use keyword "Now"] (affects generated links).

Change the column settings for the bugzilla query to only include the following columns: ID, Summary

Depending on the circumstances, you can limit the query to a specific Gecko branch by using the fixedbranch and verifiedbranch keywords.

Use the following JavaScript bookmarklet to change your bugzilla query into a query which uses bug numbers.
Bookmarklet to convert bugzilla query list to bugzilla id list
```
javascript:(function(){var y,i,L,x,a; y = ''; for (i = 0; i < document.links.length; ++i) { L = document.links[i]; x = L.href; a = L.innerHTML; if (x.substring(0,45) == 'https://bugzilla.mozilla.org/show_bug.cgi?id=' && x != document.location.href && a != 'First' && a != 'Last' && a != 'Prev' && a != 'Next') y += ',' + parseInt(x.substring(45,62)) } if(y.length) document.location.href='https://bugzilla.mozilla.org/buglist.cgi?bugidtype=include&order=bugs.bug_id&bug_id=' + y; else alert('no buglinks on this page'); })();
```
The easiest approach is to copy the previous change to the new version (~/SpiderMonkey/release-notes/JS_version.html) and edit it to remove the existing list of fixed bugs, then copy/paste the source from the bugzilla query into the new document.
CVS
Do a Bonsai query on the appropriate module/branch for directory mozilla/js for Date in the same range as used in the Bugzilla query. Compare the Bonsai query results to the Bugzilla query, adding or removing items from ~/SpiderMonkey/release-notes/JS_150_RCnew.html to make sure the report contains all bugs checked into the mozilla/js/src and mozilla/js/jsd directories while ignoring any checkins to mozilla/js/src/xpconnect.

NOTE:

Do NOT imitate the web version: http://www.mozilla.org/js/spidermonkey/release-notes/JS_160.html.

The www.mozilla.org build process inserts extra HTML elements above and to the left of your own content.
In the editing process, change the HREFs for the bug hyperlinks from the above query from relative to absolute;
e.g. from href="show_bug.cgi?id=137000" to href="http://bugzilla.mozilla.org/show_bug.cgi?id=137000".
Remove all CSS |class| attributes from the HTML; otherwise, some of the anchors will be red (for "Critical" bugs), etc. etc.
Make sure that the HREFs at the top of the document (for "ID", "Sev", etc.) do not include "Now". (See "dates" parameter above).
Of course, if you have optimized to a hard-coded bug number query as described above, this will not be relevant.
The details in the "Highlights" section can be taken from bonsai. For example, look at the bonsai comments
for recent checkins to mozilla/js/src/*.c for ideas on what to put here.

Save to ~/SpiderMonkey/release-notes/JS_version.html

Now edit the index file ~/SpiderMonkey/release-notes/index.html by adding a new row pointing to the new html file above:

Tag the SpiderMonkey release

Note: do NOT cut a branch; i.e. do NOT do cvs -b

foo@bar.com:~
$cd ~/SpiderMonkey/newversion/src

foo@bar.com:~/SpiderMonkey/newversion/src
$cvs -z3 -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
tag JS_newversion

foo@bar.com:~
$cd ~/SpiderMonkey/newversion/jsd

foo@bar.com:~/SpiderMonkey/newversion/jsd
$cvs -z3 -d ":ext:foo%bar.com@cvs.mozilla.org:/cvsroot" \
tag JS_newversion

Prepare Tarball containing the release.

POINT TO REMEMBER:

Wait for mirror server to update after you tag the SpiderMonkey source. It should take no more than 1/2 hour.

After you make the appropriate JS tag for the release, you should do an anonymous checkout of the source into a fresh location and use it to create the SpiderMonkey release tarball. This will create the appropriate CVS directories with the anonymous login info will be contained in CVS/Root files througout the tarball, and will allow the user to update his tree directly from CVS if he wants.

Checkout the source

foo@bar.com:~/SpiderMonkey
$mkdir -p tarball/js

foo@bar.com:~/SpiderMonkey
$cd tarball/js

foo@bar.com:~/SpiderMonkey/tarball/js
$cvs -z3 -d ":pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot" \
co -r JS_newversion -d src mozilla/js/src

foo@bar.com:~/SpiderMonkey/tarball/js
$cvs -z3 -d ":pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot" \
co -r JS_newversion -d jsd mozilla/js/jsd

Verify that the checked out source is from ":ext:anonymous@cvs-mirror.mozilla.org:/cvsroot".

foo@bar.com:~/SpiderMonkey/tarball/js
$cat src/CVS/Root
:ext:anonymous@cvs-mirror.mozilla.org:/cvsroot

Update Windows *.mak files

The Windows-only src/js.mak, and src/fdlibm/fdlibm.mak need Windows line endings, so convert the '\n' Unix line endings in these files to '\r\n' before packaging. See bug 72234 .

foo@bar.com:~/SpiderMonkey/tarball/js
$find src -name '*.mak' -print | xargs unix2dos -D

Create README for this release from the README of the previous release's tarball and edit the README if necessary.

foo@bar.com:~/SpiderMonkey/tarball/js
$cp ~/SpiderMonkey/JS_oldversion/README README

foo@bar.com:~/SpiderMonkey/tarball/js
$emacs README

Be sure to delete any backup file created when editing README.

Create the tarball for the release.

foo@bar.com:~/SpiderMonkey/tarball/js
$cd ..

foo@bar.com:~/SpiderMonkey/tarball
$tar -vczf ~/SpiderMonkey/js-newversion.tar.gz js/

foo@bar.com:~/SpiderMonkey/tarball/js
$cd ~/SpiderMonkey

foo@bar.com:~/SpiderMonkey
$

Test the tarball

Decompress the tarball into a virgin directory

foo@bar.com:~/SpiderMonkey
$mkdir testtarball

foo@bar.com:~/SpiderMonkey
$cd testtarball

foo@bar.com:~/SpiderMonkey/testtarball
$tar -xzvf ~/SpiderMonkey/js-newversion.tar.gz

Build the debug JS shell

If you are building under Windows with MSVC, you must build from a DOS command shell. The following commands will work both under Unix/Linux and Windows.

Set up your build environment as you would when building debug Seamonkey or debug Mozilla Firefox and build the debug js shell.

foo@bar.com:~/SpiderMonkey/testtarball
$cd js/src

foo@bar.com:~/SpiderMonkey/testtarball/js/src
$make -f Makefile.ref

Build the optimized JS shell

Set up your build environment as you would when building optimized Seamonkey or optimized Mozilla Firefox and build the optimized js shell.

foo@bar.com:~/SpiderMonkey/testtarball
$cd js/src

foo@bar.com:~/SpiderMonkey/testtarballjs/src
$make -f Makefile.ref BUILD_OPT=1

check the JS version by doing ./js --help

run the JS testsuite on it in and compare the failures to those listed in the release notes. Remove any bugs listed as fixed which do not pass.

Publish the tarball to stage.mozilla.org

File a bug in mozilla.org:FTP:Staging to have the tarball placed on the ftp server. The tarball is too large to be attached to a bug, so you will have to place it somewhere that Server operations can access it.

Include these steps in the bug:

Place the new tarball js-newversion.tar.gz in stage.mozilla.org:/home/ftp/pub/js/
Move (not copy) the old tarball js-oldversion to the older-packages directory

Commit the Release Notes to http://www.mozilla.org/js/spidermonkey/release-notes/

foo@bar.com:~/SpiderMonkey
$cd release-notes

foo@bar.com:~/SpiderMonkey/release-notes
$cvs -z3 -d ":ext:foo%bar.com@cvs-www.mozilla.org:/cvsroot" \
add JS_newversion.html

foo@bar.com:~/SpiderMonkey/release-notes
$cvs -z3 -d ":ext:foo%bar.com@cvs-www.mozilla.org:/cvsroot" \
ci -m "bug xxxxxx - Updating for Spidermonkey JS_newversion release"

Announce to Newsgroups

mozilla.dev.tech.js-engine
mozilla.announce
(A moderated newsgroup. Your email won't appear right away)

Sample Email

Hello,

The latest tarball for version 1.5 of the SpiderMonkey (JavaScript-C) 
engine is now available at:

   http://ftp.mozilla.org/pub/mozilla.org/js/js-1.5-rc6.tar.gz


This is Release Candidate 6 of JavaScript 1.5, containing a number of 
bugfixes as we progress toward a final release. Note: the Mozilla 
browser may display an incorrect file date of 2003-01-30 for the tarball 
if accessed via the ftp protocol instead of http. This is a known bug 
(http://bugzilla.mozilla.org/show_bug.cgi?id=220948), and should be 
ignored. The actual date of the tarball is 2004-01-30.


A change log for this release is available at 
http://www.mozilla.org/js/spidermonkey/release-notes.

Note in particular there has been a rewrite of SpiderMonkey regular 
expression engine. Certain behavior has changed as a result. See 
http://bugzilla.mozilla.org/show_bug.cgi?id=85721 and its many related 
bugs for further details. Some changes that have resulted:

   * Improved regexp performance

   * Anything that starts like a {min,max} quantifier but doesn't parse 
as one is taken as a flat string to match, instead of throwing a 
SyntaxError (http://bugzilla.mozilla.org/show_bug.cgi?id=228087).

   * The match array now always has N+1 elements, where N is the number 
of capturing left parentheses in the regular expression, regardless of 
whether all of them are actually used or not. 
(http://bugzilla.mozilla.org/show_bug.cgi?id=123437)

      o EXAMPLE:  arr = /(a)?a/("a")
         + |arr| is now:["a", undefined]
         + (no longer): ["a"]



As always, you can get the most recent version of the JS engine by 
pulling the source code via CVS and building it locally. Details on how 
to do this are available at:

      http://www.mozilla.org/js/spidermonkey/


To pull this specific RC6 release instead of the current CVS tip, one 
would use the tag -r JS_150_RC6.


Sincerely,
Phil