> What *should* happen if we add a parameter to a JSAPI function? Should we > add it to the rust-mozjs equivalent at the same time, immediately breaking > downstream users?
Generally you'd make a corresponding change to the Rust bindings immediately and we'd have unit tests for them that ensured they worked. This will only break downstream users if they are pointed directly to the github repo as their dependency *and* they are not pointed at a specific working revision. Servo can then just update its dependency graph to include a new version and make the corresponding changes to Servo for the new API. We do this for other dependencies regularly even across breaking changes, and it's been working well. I'm not sure how often breaking changes are introduced in SpiderMonkey or the extent of the breakage, so results may vary here, but I think the end result will be a significant improvement over the current status quo. A side question here is whether there are plans to make the JS API more stable in the future (for our benefit and for other embedders)? > Who's doing the "release engineering", and what's involved? Just bumping > version numbers and running `cargo publish` from time to time? Currently rust-mozjs is not published to crates.io, so keeping it compiling and writing some unit tests and ensuring those are part of normal js automation is probably all that is needed right now. If we wanted to publish to crates.io we'd need to occasionally update the version info and do a cargo publish at some regular cadence. The Servo team doesn't have any experience with Gecko automation, but we can certainly create unit tests and other things that are missing. jack. _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
