release 0.17.0

[YeungOnion]

I think this is okay for getting some more users back.

Open to feedback on the changelog, I used release-plz to generate the log for this release and made edits for further format

Remaining active work that is related to CI will be updated and likely minor version releases to [crates.io], included but not limited to:

• code coverage reports. Note that I dropped the codecov badge on the readme for this release since it's inaccurate.
• testing NIST data

[YeungOnion]

Noting that at some point (#209) @FreezyLemon mentioned the idea of introducing MSRV to this project; I planned to delay adding that policy to the release that introduces that change that motivated it since this release is focused to get the project back on its feet.

[YeungOnion]

I got some advice that if we're going to introduce the msrv may as well not wait on it.

I did some testing with cargo-hack and found that cargo check fails up through 1.60 on nalgebra. Note that 1.61 will also suffice for #209's proposed changes regarding.

I'll make these changes now.

[FreezyLemon]

Any MSRV should really be checked in CI, since it's very easy to accidentally break it while updating dependencies. It would also be nice to document it somewhere, e.g. at the bottom of the README (including when and for what reasons it will be changed, and how the crate version will reflect MSRV changes)

[YeungOnion]

Seems like I only checked the lib in my local testing, our benches rely on criterion relying on rayon which has rust-version = 1.64

I'm okay excluding those benchmarks from the package, but I've not found a way to split the dependencies for benchmarking apart from testing, unsure if this is possible.
@FreezyLemon Do you know a way around this other than making a separate crate for testing?

[FreezyLemon]

Do you know a way around this other than making a separate crate for testing?

Another way of achieving this would be a crate feature that needs to be enabled for benchmarking, but it's not great for developer ergonomics.

It's also possible to just disable the default features for criterion which should remove rayon and possibly reduces the MSRV.

[YeungOnion]

I can get it down to 1.65 with changing the features criterion uses and keeping the version pinned, which aligns around the 0.16 statrs release. However, my opposition is that the MSRV is higher than what the statrs lib itself needs, so I find it a little misguiding. I would clearly mention this in the docs.

I don't like the option to gate benches with a feature, but given the below reasons, I think we could get by.

• the features benched aren't actively being developed it may not impede any developer
• benchmarks should be reported with version compiled with
• an MSRV higher than what our lib needs could remove it from consideration, only a few minor versions (5 months) newer.

Thoughts?

[YeungOnion]

made a post on the forums to get others' input if this would be unexpected.

[FreezyLemon]

I honestly thought that disabling the criterion default features would solve the problem. The benches feature doesn't feel great... I'd honestly just set the expectation that the MSRV is meant for crate users (cargo add statrs) and not for crate devs (git clone <statrs>) and just be done with it. dev-dependencies are not something to consider for normal crate usage, and any dev should have a recent Rust version anyways.

EDIT: The MSRV discussion has come to a point where it should probably be moved to its own thing.

[YeungOnion]

I agree, and it makes me wonder if it's better to

• hold off on an MSRV
• disable/remove benches to make sure that CI is checking behavior that a lib user would see
• have CI only check MSRV only for the lib target, not its tests (or benchmarks)

I'm leaning toward the last option, but it's potentially hiding a source of inconsistency in test results.

[FreezyLemon]

Holding off for this release doesn't seem like too big of a problem IMO. That would allow some time to discuss this in a separate issue etc.

If you do want to include it for this release, I'd prefer option three as well. As I said above, dev-dependencies shouldn't be of concern to a crate user, and it should be fine to have a higher version prerequisite for contributors

[YeungOnion]

Think I'll hold off on it. Since inclusion of it is only policy, I imagine it would only change the fix release version.