- I think this is a great idea and I'm thrilled that Wes is taking the job.
- Let's call it 1.8.5 and libmozjs185. SpiderMonkey version numbers have
historically tracked the language version, not the Gecko version.
- We will not take any patches (in the tracemonkey repo or mozilla-central)
before Firefox 4 ships for this purpose.
- We will not take any patches in the stable Firefox 4 release branch
for this purpose either.
- Wes's plan, as I understand it, is to wait for Firefox 4 to ship, take
that revision (the one we ship), make minimal changes to it (which will not
land upstream, at least not instantly), *maybe* throw in NSPR or something,
and tar it up. Sounds good to me.
> - run autoconf213 in js/src so that we ship a working "configure"
> - steps related to Makefile.ref, js.mak, etc elided
> - I have not updated the change log. Is this really necessary? Is there a
> non-manual way to do this? There were ... several ... changes made between
> 1.7.0 and 1.8.5
> - Obviously, CVS tagging no longer applies. How about we tag the hg rev we
> push with bug 586016?
If you intend to base the source release off Firefox 4 final, that will already have a tag. There's no point tagging it more. The source release's README that explains what revision it's based on and what changes you made.
> - Tar now has one more top-level directory -- this is to allow us to ship
> things like NSPR and jemalloc later if we want to in the same tar ball
> - README moved to higher level dir
Great.
> Also.... Can I please, please change "libmozjs.so" to a better name in the tar
> release? How about libmozjs185.so.1.0.0? I think this would help the distro
> use-case, and make it possible to ship bug fixes on top of
> JS-1.8.5-the-language -- while properly advertising API/ABI compatibility. And,
> of course, making room for JS-1.8.6-the-language.
Wes clarified on IRC that he means a one-line change. The Makefile.in in the source distribution would have a different LIBRARY_NAME= than trunk. I think this is a good idea. It is definitely better than stopping right now to figure out an ideal versioning story.
Delivering something called "libmozjs185" makes it easy for us to adopt a completely different and superior versioning scheme later with no risk of breaking people who adopt this release.
A few points:
- I think this is a great idea and I'm thrilled that Wes is taking the job.
- Let's call it 1.8.5 and libmozjs185. SpiderMonkey version numbers have
historically tracked the language version, not the Gecko version.
- We will not take any patches (in the tracemonkey repo or mozilla-central)
before Firefox 4 ships for this purpose.
- We will not take any patches in the stable Firefox 4 release branch
for this purpose either.
- Wes's plan, as I understand it, is to wait for Firefox 4 to ship, take
that revision (the one we ship), make minimal changes to it (which will not
land upstream, at least not instantly), *maybe* throw in NSPR or something,
and tar it up. Sounds good to me.
> - run autoconf213 in js/src so that we ship a working "configure"
> - steps related to Makefile.ref, js.mak, etc elided
> - I have not updated the change log. Is this really necessary? Is there a
> non-manual way to do this? There were ... several ... changes made between
> 1.7.0 and 1.8.5
Skip the changelog. Point to http:// hg.mozilla. org/tracemonkey if you think anybody cares.
> - Obviously, CVS tagging no longer applies. How about we tag the hg rev we
> push with bug 586016?
If you intend to base the source release off Firefox 4 final, that will already have a tag. There's no point tagging it more. The source release's README that explains what revision it's based on and what changes you made.
> - Tar now has one more top-level directory -- this is to allow us to ship
> things like NSPR and jemalloc later if we want to in the same tar ball
> - README moved to higher level dir
Great.
> Also.... Can I please, please change "libmozjs.so" to a better name in the tar so.1.0. 0? I think this would help the distro 5-the-language -- while properly advertising API/ABI compatibility. And, 6-the-language.
> release? How about libmozjs185.
> use-case, and make it possible to ship bug fixes on top of
> JS-1.8.
> of course, making room for JS-1.8.
Wes clarified on IRC that he means a one-line change. The Makefile.in in the source distribution would have a different LIBRARY_NAME= than trunk. I think this is a good idea. It is definitely better than stopping right now to figure out an ideal versioning story.
Delivering something called "libmozjs185" makes it easy for us to adopt a completely different and superior versioning scheme later with no risk of breaking people who adopt this release.