Prepare 0.10.0-rc.0

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.

[dhardy]

I checked repo history; doesn't look like anything is missing from the CHANGELOG.

The only significant change outside the rand crate is #1641 which is technically a breaking change to rand_core, but it doesn't look like it will affect any of our implementations, so I think we're safe ignoring this discrepancy between master and rand_core v0.9.3 (everything else should be using the published version anyway).

Insignificant changes include #1653 which affects rand_pcg, but I see no need for a new release of that crate.

rand_distr will require an update; lets publish a rand pre-release first then update rand_distr to use that.

[newpavlov]

which is technically a breaking change to rand_core

Maybe we should consider cutting breaking releases for rand_core and getrandom after all?

[dhardy]

Maybe. Is there incentive for a getrandom release?

[dhardy]

I'll continue as planned for this pre-release in any case.

[newpavlov]

Is there incentive for a getrandom release?

As I wrote in the other issue, it would allow us to rely on the MSRV-aware resolver (i.e. we will be able to bump getrandom's MSRV freely) and to remove the wasm_js backend in favor of the opt-in fallback.

[dhardy]

@newpavlov Sounds like we have sufficient rationale to make new breaking releases of those too then.