Subj : Re: Getting a new SM version To : Celso Aguiar From : Brendan Eich Date : Wed Dec 17 2003 11:08 am Celso Aguiar wrote: > I'm considering getting a newer version of the SM engine for our app > (we're using 1.5 RC4a, so it's pretty old). I normally would go with > the latest one provided in the ftp site: > http://ftp.mozilla.org/pub/mozilla.org/js/js-1.5-rc5a.tar.gz (from > 29-May-2003), but I see there's also one provided with the source code > for the latest mozilla milestone (1.6b - from December 9, 2003). > The Mozilla milestone is advertised as "the most stable of our builds" > and is closer to the bleeding edge (nightly). We want to stay closer > to the edge, but don't want to compromise stability. If you check out bonsai.mozilla.org, query for changes to js/src, you will see what's been changing. Evaluating those changes, following the generated links to the bugs from the bug numbers in the checkin comments, is a good way to get a feel for activity. It's not as if the edge is bleeding. SpiderMonkey is over seven years old now, and we have extensive testsuites for it (js/tests, plus the DOM tests and all the Mozilla apps). The big change in 1.6, discussed below, seems to have settled down. > What's the > difference in stability between the two? Is the one in the ftp site > more stable in any way? I would say it's simply older, so any changes made since it was released have not had the "soak time" of changes in it -- although it may have included last-minutes changes too. "Soak time" != stability, but if the changes are in code that's being executed frequently, then soak time without bugs being reported does suggest that the code is not buggy -- it's not known to be buggy yet. The flip side is that an older snapshot has bugs we now know about and have fixed, or even bugs we knew about, but hadn't had time to fix. So if you get, e.g., the 1.5final version of SpiderMonkey, you'll miss out on the fixes we did for 1.6 (and maybe on some regressions we happened to introduce). All real code has bugs, of course. Sorry if this is too basic. My point is that, given the testing we do, we have increasing confidence in more recent releases. We don't measure and chart stats as if the code's bugginess were like the weather, because changes are more orderly. Also, we teach our testsuite about all regressions, so we can avoid re-regressing. But no test suite can be guaranteed to cover all cases, even for known bugs. > Any reason not to get the one from milestone? First, we do alpha, beta, and final milestones, per the roadmap, so you should take those designations to heart. Alpha is riskier than beta, which is riskier than final. So if you can choose a final Mozilla milestone over its beta version, do so. Second, in the case of 1.6b, I think you may want to consider the patch-landing I did of rogerl's big jsregexp.c rewrite (bug 85721, http://bugzilla.mozilla.org/show_bug.cgi?id=85721). That landing made things faster, but it added a few bugs, and a few incompatibilities (per the ECMA spec) that we would rather remove (preferring to be less than strictly ECMA compliant where the difference is that we tolerate extra braces or parens in regular expressions). I have one more regular expression rewrite followup fix (bug 228087) to do for 1.6final, but there may be other minor issues with the new regexp code that will only come out in the wash, later. If you depend heavily on regular expressions and don't mind the bugs that you've lived with in the RC4a version of SpiderMonkey, then maybe you don't want to take any chances with 1.6. But you should look at the bonsai query results for the rest of js/src/*.[ch] to see if there are other fixes you do care about. You might also query bugzilla for bugs closed in recent milestones (when was RC4a, anyway?). /be .