It would be nice if these changes could be done in a purely additive manner with any breaking changes as a last resort and kept as minimal as possible.

This crate has been post-1.0 for over 5 years and any unnecessary changes will cause breakages/churn.

@tarcieri How about this commit?

@bxf12315, could you please add a description to this PR ?
I'm trying to help with the review but I got initially confused.
Let's add CVSS v3.1 support for Temporal and Environmental Scores.
And also link related issues ?

Note that mod.rs is the older, Rust 2015 convention, and we use the newer Rust 2018 convention with files named after their respective modules: https://doc.rust-lang.org/edition-guide/rust-2018/path-changes.html#no-more-modrs

Please don't use mod.rs, and if we haven't already, we should enable the lints to deny it.

For the base group, dubbing the file 'attack_vector.rs', instead of 'av' is clear about its purpose, especially because there are many files such as 'ac', 'av', etc.

@gildub you are suggesting breaking changes that are more or less bikeshedding. This crate has been stable, for many, many years. Please don't make any superfluous changes, and please follow the existing conventions.

@tarcieri,

Regarding the mod.rs style, I thought it was the other way around, thanks for the link !

Regarding the file names, shouldn't the file name reflect the struct it contains ?
That doesn't seems superfluous because, for exemple, 'src/v3/temporal.e.rs' file is handling ExploitCodeMaturity structure not e structure and that doesn't seem to be respecting Rust practices. Also the existing code seems to not have such convention.

@tarcieri,

Regarding the mod.rs style, I thought it was the other way around, thanks for the link !

Regarding the file names, shouldn't the file name reflect the struct it contains ? That doesn't seems superfluous because, for exemple, 'src/v3/temporal.e.rs' file is handling ExploitCodeMaturity structure not e structure and that doesn't seem to be respecting Rust practices. Also the existing code seems to not have such convention.

@gildub I'm not good at naming, but I personally think that naming conventions consistent with the whole project are reasonable.

Hi @xiabai,
could you please clarify if you agree with changing the files names to more explicit names or not ?

Hi @xiabai, could you please clarify if you agree with changing the files names to more explicit names or not ?

I do not think change file's name is necessary. Keep changes to a minimum.

Hi @xiabai, could you please clarify if you agree with changing the files names to more explicit names or not ?

I do not think change file's name is necessary. Keep changes to a minimum.

@gildub the changes you are proposing are, at best, off-topic for this PR. Please open a separate issue.

@tarcieri How to trigger the github workflow, I find an compile error, it's just happened on rust 1.6, I want to rebuild it.

@bxf12315 it should run automatically from now on

So yeah, this PR includes many, many breaking changes by decomposing what are currently inherent methods into traits.

That's not necessarily a dealbreaker for this PR but it will signal the start of another breaking release cycle where it would be good to also address #1087, and would therefore delay any usage of these new features outside of prereleases.

I think it can probably still be written in a purely additive way that doesn't break any existing APIs (again, this is a v2.0 crate which has been stable for many years), and perhaps introduce those changes separately in a PR that starts a new breaking release cycle.

So yeah, this PR includes many, many breaking changes by decomposing what are currently inherent methods into traits.

That's not necessarily a dealbreaker for this PR but it will signal the start of another breaking release cycle where it would be good to also address #1087, and would therefore delay any usage of these new features outside of prereleases.

I think it can probably still be written in a purely additive way that doesn't break any existing APIs (again, this is a v2.0 crate which has been stable for many years), and perhaps introduce those changes separately in a PR that starts a new breaking release cycle.

ok, I got your point, I will drop these three traits MetricScore and ScopedScore, and ModifiedScore, keep the old logic.
I will try to update them before the weekend.

@tarcieri updated, please check again.

@tarcieri please review the PR. Thanks

@tarcieri hi please review the PR. Thanks

@bxf12315 I will try to review soon, however I am the maintainer for a large number of projects and this PR is something of a lower priority to me

I'm a little confused how referencing std didn't break CI

Please check again. Thanks