0.13.1 -D parse error: breaking change?

[kellerkindt]

See, this is what happens if you do not pin your dependency versions ... (talking to myself)

[kellerkindt]

PR #278:

Changing --deny-warnings to take an argument is a breaking change that might catch people off guard. [...]

Well, I was caught off guard...

[tarcieri]

I actually changed --deny-warnings specifically to continue to work as-is sans argument in #278 to make this change slightly less disruptive. That now prints a deprecation warning and tells you to use --deny warnings.

For -D, I wanted to better align with RUSTFLAGS and accept similar arguments. -D is now short for the new --deny option and takes an argument. The same -D warnings you'd use with RUSTFLAGS now works with cargo audit.

Pardon our dust.

[kellerkindt]

Well, all in all the change is reasonable.

[bmc-msft]

It would be extremely valuable to declare how you intend to manage versions. This breaking change came in 0.13.1.

One of many common practices that would prevent surprises like this in the future would be to use semantic versioning.

[tarcieri]

@bmc-msft this project uses semantic versioning, even if it isn't declared as such.

v0.13.0 was yanked.

As I just mentioned above, #278 introduced in v0.13.1 to make the changes from #206, which actually added an argument to -D/--deny-warnings, slightly less disruptive. The changes from #206 were originally a part of v0.13.0.

[bmc-msft]

It's useful that you're intending to use semantic versioning.

I saw the release of 0.13.0 when it was first published, looked through the changelog and code and did not see anything that would break our usage.

The follow-on release of 0.13.1 that introduced a breaking change was what caught me off-guard.

[tarcieri]

#206 was a breaking change. It looks like it was not properly noted in the changelog.