Upgrading embedding from ESR78. Any important changes?

SpiderMonkey
#1

Hi everyone.

I think that this is now the replacement for the old mozilla.dev.tech.js-engine mailing list ([https://groups.google.com/g/mozilla.dev.tech.js-engine/c/hkqD0xh3nRs])

Over the last year we have done the massive task of upgrading our embedding to ESR78 (from 1.8.5). Now that we’ve done that I want to make sure that we keep up to date as I don’t want to have to go through that again! :worried:
Looking at the Firefox release calendar it looks like the next ESR release will be ESR91 in July and I would like to target this as the next release to move to.
Looking at treeherder it looks like the current release is 87.

Can anybody recommend if I should try to upgrade to the current release and then upgrade again to ESR91 later in the year or would I be better just waiting for ESR91 and upgrading in one step?
Are there any big changes that I should be aware of (either in terms of API changes or toolsets required for compiling etc) that have already happened or that are planned between now and ESR91?
If anybody has any thoughts I would be very grateful.
If I’m better asking this in chat.mozilla.org instead then please let me know.

Many thanks

Miles

#2

This is a great place for that question. While the current release is 87, the current dev branch is 89. If your plan is to start targeting ESR91 when it comes out and want to get a head start, then I might suggest targeting whatever version is in Beta (See https://whattrainisitnow.com/). This avoids the churn of trunk but keeps you close enough to central that small ergonomic issues are more likely to be fixed in time if you raise them.

In terms of embedder-facing changes between now and ESR91, the team is planning a spring-cleaning sprint at the end of April and that may include projects like splitting more parts of jsapi.h into individual files, or tweaking how test suites are organized.

If you started targeting Beta 89 (in 5 days), I anticipate that embedding API breakage between that and 91 will be pretty mechanical to fix.

It would be helpful to take a few notes as you work so we can update the migration guide.

1 Like
#3

That’s very useful. Thanks for the information.

Can I just check then…
What’s the best way to download a beta version of Spidermonkey?

At https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr78/docs/Building%20SpiderMonkey.md#getting-the-source-code it suggests downloading the Firefox source.
That’s not actually what I did when I downloaded ESR78. I went to https://treeherder.mozilla.org/jobs?repo=mozilla-release&searchStr=spidermonkey-sm-package and clicked on the first SM (pkg) link I came to. I got that method from reading about it somewhere on Mozilla a long time ago…

Should I go to https://treeherder.mozilla.org/jobs?repo=mozilla-beta&searchStr=spidermonkey-sm-package instead and click on the latest SM (pkg) link or is there a better/alternative way I should be downloading it?
Again, any advice gratefully received!

BTW, I hadn’t come across https://whattrainisitnow.com/ before. Useful! :grinning:

Thanks

Miles

Having trouble compiling Spidermonkey for 32 bit Windows, MSVC
#4

“Official” bundles of spidermonkey are still not a solved problem. For development purposes, using the SM(pkg) builds of beta are probably a good option. They are updated twice a week, but the changes should just be bug fixes.

For production purposes (using ESR builds), we do recommend using the Firefox ESR source bundles from ftp.mozilla.org. The reason is that those are the versions we track for security updates and it avoids accidentally getting an in-between version. The difficulty with the SM(pkg) approach is it is hard to know precisely which version QA signed off on and was shipped as a browser product and which commits are just staged so that QA can start testing.

On the eternal team backlog we’ve got an item to try and generate the pkg tarball and ship it to the “https://ftp.mozilla.org” site using the same commit that goes out the door as product. There are a few hiccups here we just haven’t found time to deal with. Unsurprisingly, I do not personally have the ability to sign anything with production keys :slight_smile:.

#5

Thanks. That makes sense. Noted about getting the Firefox ESR source bundles from ftp.mozilla.org too.
Presumably there is no difference in the way that Spidermonkey should be built, if it comes from the SM(pkg) or the Firefox ESR source bundles? You cd to js/src and build there using the instructions at https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr78/docs/Building%20SpiderMonkey.md#building-spidermonkey.

I guess the Firefox source downloads are just a lot bigger than the SM(pkg) ones! :wink:

#6

Yeah, should be able to just follow the same build instructions. The SM(pkg) process runs the js/src/make-source-package.sh script that makes a stripped down tarball, but with files in the same tree structure.

We were chatting in channel and noticed that what happens in the Debian mozjs78 source package is the full Firefox source tarball is pulled from https://ftp.mozilla.org, signature is verified, the make-source-package.sh script is used, and the resulting tarball contents (plus distro .patch files) for the source in Debian. Our friends at the GNOME project maintain the mozjs78 repo since it powers a number of things in GNOME.