Consider version number 0.1.0 to enable non-breaking updates

[SimonSapin]

The current version number is 0.0.114, so the next one is at least 0.0.115 which Cargo considers incompatible. Switching to 0.1.0 would open the choice for the following one to be either 0.2.0 or 0.1.1, depending on whether it’s breaking or not: servo/servo#15224

[shssoichiro]

Usually, clippy releases are incompatible between point versions, because clippy relies on internal compiler features which change rapidly between nightlies. I would think bumping clippy to 0.1.0 is not the best idea until compiler plugins become stable.

[SimonSapin]

In this scheme you could keep making incompatible version, for example 0.37.0 to 0.38.0. Only you’ll have the option to do 0.37.1 as well, if that ever becomes desirable.

That said, I originally filed servo/servo#15224 in case a given crate’s maintainers had not considered the way Cargo handles 0.0.x. If you decide anyway that 0.0.x is right for clippy, feel free to close this.

(Servo uses the clippy_lints crate, but it uses directly without an intermediate dependency so updating it for a breaking version is much less of a burden than, say, serde.)

[Manishearth]

Lint plugins the way clippy uses them will never stabilize.

We consider clippy to be stable because it is a tool. Any instability is not due to the compiler internals, but due to lints changing semantics drastically, which is pretty rare.

I do want to release a 1.0, but had some requirements on what 1.0 means, which weren't met yet.

@llogiq @mcarton @oli-obk should we just release 1.0.0 now?

[llogiq]

I'd like to finish the bikeshedding first.

[Manishearth]

(See https://github.com/Manishearth/rust-clippy/issues/1358)

[SimonSapin]

To be honest I don’t care much about clippy versioning, as I’ve said updating it in Servo is relatively easy either way. So I’m tempted to close or mute this issue and move on. But for the sake of the argument:

I think that whether clippy is considered "stable" is an entirely separate discussion from what I’m proposing. To Cargo, updating from 0.2.0 to 0.2.1 is exactly the same as updating from 2.0.0 to 2.1.0 or to 2.0.1. (Assuming dependencies declared with the default syntax and not more specific ranges.) Choosing one or the other is only a signal for humans. I have no opinion about what clippy’s versioning should signal to humans.

Only that if you ever want to make an update that happens, just this time, to be compatible with the previous version, with 0.0.x you can’t pick a next version number that Cargo interprets as compatible.

[llogiq]

To give a different perspective to this discussion, what would it mean for two clippy releases to be compatible? Can one add lints (even if that means additional warnings/errors)? Can we change a lint to fix false negatives (or false positives) and still be 'compatible'? Or is corresponding to a rustc release the only determining factor?

[phansch]

The compatibility concerns should be addressed by the RFC.
Also, since Clippy is now no longer available via Cargo, I'm going ahead and closing this issue.