Why are old versions of `pretty-assertions` more popular?


#1

Why do people prefer old versions of pretty_assertions? :confused:
Do new versions have a flaw I am unaware of?

Here are some numbers…

Downloads as of 2017-10-17

… over the last 90 days

… per version

Version Downloads Release Date
0.1.0 105 March 26, 2017
0.1.1 44 March 29, 2017
0.1.2 16_725
(avg. 110 per day)
March 29, 2017
0.2.0 708 April 29, 2017
0.2.1 6_295
(avg. 54 per day)
June 24, 2017
0.3.0 26 August 30, 2017
0.3.1 18 August 31, 2017
0.3.2 20 August 31, 2017
0.3.3 18 September 1, 2017
0.3.4 573
(avg. 12 per day)
September 2, 2017
0.4.0 8 October 15, 2017

Versions compared

v0.1.2

v0.2.1

v0.3.4

v0.4.0

Projects on GitHub

There are 61 Cargo.toml files on github containing the string pretty_assertions (as of 2017-10-18). I checked roughly 20 of them via blame. I compared the crate version in Cargo.toml with the most recent pretty_assertions version at the commit date the dependency was introduced.

Only 1 out of 20 crates (5%) was using an outdated version. Thats not a significant number. On the other hand 95% were using the most recent version at the time of introducing pretty_assertions.

So, at first glance it looks like (a) earlier versions of pretty_assertions just had more impact on the crates and (b) a lot of people are not updating their dependencies very regularly. Could that be it?


#2

… So, please let me know if you think pretty_assertions needs some improvement. :slight_smile:


#3

This would be my guess, and it’s particularly so for the nature of your crate. Presumably, people’s tests (assertions) don’t fire all that often, and so it’s probably not something someone would actively see if there’s a newer version of with better output.

It’d be cool if there was some RSS feed (or something) from crates.io telling someone a cargo.toml dependency in their project has a newer version; an IDE would be an ideal place to surface this, perhaps. Maybe this exists already, don’t know.


#4

I really love the newer version of pretty-assertions, but even so I’m sure a couple of my older projects are still using an older version. I think it’s just that you need to manually update the semver version in your Cargo.toml (because * versions are frowned upon), and like all manual things there’s a good chance you’ll forget about it or never get around to looking up the new version number.

It’d be nice if cargo update could let you know if there are newer versions of a dependency outside the range you’ve specified in Cargo.toml. I also use the cargo-edit package so adding a dependency is just a case of running cargo add pretty-assertions. But then that adds the strictest version number possible to your Cargo.toml, meaning we’re back to the problem mentioned earlier.


#5

cargo add does add a full version number, but an unadorned “1.2.3” is the same as a caret requirement “^1.2.3”, which allows newer semver-compatible versions to be used. A simple cargo update should resolve to the newest possible. If it were “=1.2.3”, this would allow only an exact match.

See more in the docs for specifying dependencies.


#6

Oh nice! I can never remember exactly how semver specifiers work so I always end up having to go to that page on crates.io to help jog my memory :stuck_out_tongue_winking_eye:


#7

Theres is cargo outdated

$ cargo outdated
Name             Project  Compat  Latest   Kind         Platform
----             -------  ------  ------   ----         --------
clap             2.20.0   2.20.5  2.26.0   Normal       ---
clap->bitflags   0.7.0    ---     0.9.1    Normal       ---