Cargo.toml: loosen dependency version on chacha20

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!

[baloo]

Summary

Not binding to a strict version of chacha20 (only a minimum) would make for a much smoother release process. Especially to get over the API breaks humps coming in rand_core 0.10.0-rc.3

Motivation

Details

[dhardy]

Not strictly restricting the patch-version of rand_core v0.10.0-rc-2 is why CI is currently broken. Semver allows breaking changes in any pre-release version.

[baloo]

Please commit the cargo.lock then. This is what it is used for.

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

I’m doing integration work in large consumers of the rustcrypto ecosystem (tss-esapi, rpgp, …) that proved to be helpful chasing down bugs early in release cycle. Having to unpin version for every dependency would be a lot more work than it currently is.

[dhardy]

Restricting the version in the cargo.toml makes it hard (requires a patch on top, and a git branch, more work) to test changes in downstream crates.

What I don't understand here: you want to use rand with a downstream crate and the new rand_core 0.10.0-rc.3; this requires a patch to rand regardless of the version dependency here (until #1697 is merged).

Hence, this only benefits cases where pre-releases are not API-breaking (or at least not affecting some dependency) IIUC?

I can see some benefit then, but it's not as simple as this PR; it also requires committing Cargo.lock as @tarcieri mentioned. I suppose we can do that, but please open a new PR and write a good motivation section. The tests likely also want tweaking (update instead of generate-lockfile maybe?).

We ought to merge #1697 first. In any case, I'm off now for a few days; happy Christmas (if relevant to you).

[baloo]

Happy Christmas to you too!

I've opened a follow up PR with the Cargo.lock: #1699

Yeah, I definitely require #1697 (and I have a branch with both the loose version of chacha20 and #1697 already). But it'd be nice to have both!