bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
Bug 646915 (jssrc)

Improve JS source release process




JavaScript Engine
7 years ago
4 years ago


(Reporter: Wesley W. Garland, Unassigned)


Mac OS X

Firefox Tracking Flags

(Not tracked)




7 years ago
I'd like to improve the JS source release process.

Historical JSAPI releases have been
 - few
 - far in-between
 - one or two per JavaScript version
 - API compatible
 - ABI incompatible
 - versioned based on the JS language they implement with an optional -suffix

I would like future JS releases to maintain most of these characteristics, however I would like to add the following properties
 - A version number which indicates API and ABI compatibility
 - A product name which identifies the version of JS we are implementing
 - Plays nicer (even if not nice) with OS distros and packaging systems

To that end, I've put together JS 1.8.5 with an experimental naming convention and versioning scheme, documented in the release's README.

The key idea is to produce a source release which satisfies the needs of the embedders and distro guys with the absolute minimum delta from a known-stable (i.e. Firefox-release) snapshot.

However, some delta is required, as we don't want some of these changes in the Moz tree, and we may want to cherry-pick a patch or two from the Moz tree (say, for a trivial but critical bug) between Firefox releases.

I'm volunteering to manage the source release (using JS 1.8.5 as the experimental proving ground with
 - super-review from JS peer
 - review for patches from the peer group { me + distro maintainers }

Note that the point of this exercise isn't to place extra work on JS folks by maintaining multiple source releases, requiring API compatibility, or anything crazy like that.  The versioning scheme I have proposed is based on current reality.

This lets the embedder/distro community have better, more regular releases without polluting the tree or tying up resources -- while still providing an accountability mechanism in the form of super-review.

Comment 2

7 years ago
Can you explain why "some delta is required", as opposed to #define'd off with a --enable-source-release flag, or something. (I'm thinking in terms of having automated testing in the form of an SM flag on tbpl.)

Comment 3

7 years ago
Delta is required for two reasons:
 1. Some things, like the library versioning tweaks, will not be taken upstream (or so I have been told)

 2. It is likely that if we need to pull a small/critical from the mainline into the source release that we will cherry-pick just that patch, rather than trying to capture, stabilize, discover, and document whatever API and ABI changes occurred between the source release and when that particular patch happened to land.

Take a look at the patches/ subdir of the src release, all three are perfect examples.

 - One is embedder-only build system changes
 - One is a version stamp that can't land in the mainline and be correct (unless we make a new head, which is silly)
 - One is a cherry-picked patch that we wanted for the source release but which did not land in our sync-point, Firefox 4... and other patches landed on the mainline in the meantime


4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.