Publish mozjs to crates.io again

[jschwe]

Now that we have solved the problem of vendored Rust dependencies, it should be possible to publish to crates.io again. This would mainly mean smaller downloads during builds, since we don't need to clone the whole repo anymore.

[simonwuelker]

I believe this would also unblock servo/servo#26275

[redfire75369]

Do we know the exact size limit that is set for crates.io? The last release was 37.5 MiB, but its possible the limit was 50 or 100 MiB, and you would need to contact the crates.io team to increase the limit further.

As per #617, currently ~145 MiB.

[jschwe]

I believe the relevant size refers to the compressed size, which should be roughly around 30MB. I don't know the actual limit, but if we find out that's it not enough, we could reach out and ask for more (the default limit is 10MB, so we clearly have more than the default)

[jschwe]

@jdm @sagudev What do you think about publishing mozjs to crates.io again? Would one of you go ahead, or are there still blockers I haven't considered?

[sagudev]

This biggest problem is semver, it's nice to be able to break stuff anytime (and this can happen anyway because of SM).

[simonwuelker]

I mean, there's no shame in staying on 0.x versions forever if SM doesn't expose a backwards-compatible interface...

[jdm]

It might force us to abandon our current version scheme which reflects the version of SpiderMonkey in use. I can try publishing the current version tonight and see what happens.

[jschwe]

This biggest problem is semver, it's nice to be able to break stuff anytime (and this can happen anyway because of SM).

I don't think we need to respect semver for mozjs releases. It doesn't make sense, since we couldn't make any meaningful promises anyway. We could perhaps document that in our readme.

[sagudev]

This biggest problem is semver, it's nice to be able to break stuff anytime (and this can happen anyway because of SM).

I don't think we need to respect semver for mozjs releases. It doesn't make sense, since we couldn't make any meaningful promises anyway. We could perhaps document that in our readme.

Aren't we forced to respect semver by cargo? Well we can always say that users should use exact version specifier =0.11.5.

[jdm]

Running cargo publish -p mozjs_sys --features libz-sys failed to publish due to a 408 error response.

[jschwe]

Aren't we forced to respect semver by cargo? Well we can always say that users should use exact version specifier =0.11.5.

It's not required, only strongly encouraged.

These are only guidelines, and not necessarily hard-and-fast rules that all projects will obey.

Running cargo publish -p mozjs_sys --features libz-sys failed to publish due to a 408 error response.

--features should have no effect during publish, since its publishing the whole package anyway.
408 is a timeout, so perhaps you could try again at a later time?

[jdm]

--features has an effect during verification when it builds the crate. One of libz-sys or libz-rs is required, or disabling verification.