Yep, it is.

This will also hopefully limit the number of issues opened that are resolved with a “you must enable X feature.”

As far as I know, no one has yet been able to reproduce the binary with the source code, so I don’t think the contents of it are confirmed at all.

If someone does fork serde, can they at least make it so it actually follows semver?

Hey, maybe this will actually lead to standardization of feature documentation? It’s been in terrible shape for years. The fact that optional dependencies and features have been treated nearly the same by cargo, but treated differently by crates.io, makes it useless for discovering features for crates. Up until now, my go-to method is to examine the Cargo.toml file directly, and if I can’t figure out what a feature does there I look directly at the source code.

Can you give a code example of what you have tried to do already?

I can’t say I’m surprised. I was honestly wondering how this backlash would affect kornel; it can’t feel good to get such a negative response on an open source project like this, and I feel bad for him. While I strictly don’t agree with the actions done against crypto crates, especially not the marking of an active crate as deprecated, I thought that some of the other reactions to things like marking crates as non-semver compliant were overblown.

Specifically, I think one of the cases definitely was an accident, as it probably was made at a point when it really looked like the author was doing the same 1.0.x format that some other notable crates are guilty of, even thought that turned out to not be the case.

Ultimately, this is a good example of why crates.io is so hesitant to be opinionated at all about anything, which is I think a big reason why something like lib.rs came into existence anyway. If anyone has been wondering why crates.io is so hesitant to stop people from squatting crates names, it’s because they would get reactions like this. Being opinionated means things will get political and the community may divide themselves over it.

Dang, this 3 year old post sure is hot.

The community tends to favor more permissive licenses in general. I think a lot of it is due to a large amount of core libraries (often owned by members of the core team, in Rust nursery, or otherwise central to the ecosystem) using MIT or Apache 2.0, which means users who begin publishing their own libraries and know next to nothing about licenses will just follow suit.

I do wonder how it would hold up on court to basically clone something by rewriting it in a different programming language and then relicense it. I’m no lawyer though, I have little understanding of how these things work.