How to decide if a cargo crate is "production ready"?


I'm working on a tool where I need to figure out if a cargo crate is stable or not.
I'm aware I can check for a major/pre release tag in the version.
However, this becomes a bit tricky for crates that are stable and use the 0.x.x version numbering.
One thing I imagine could work would be if crates had a way of publishing their development statement, something similar to Pypi's Development Status classifiers.

So, questions I hope I can get some answers with :

  1. Is there a way to check the development status of a cargo crate?
  2. What would be the best way to check the stability status of a crate?

What exactly do you mean by "stable"?

1 Like

Great question.

I stumbled on Adam Johnson's The Well Maintained Test and since I've been learning Rust for a couple weeks, I thought it would be fun to write a rust crate that tries to programmatically answer all 12 questions.

So, my question about stability directly translates to answering the first question : Is it described as “production ready?”

A good way to answer this for a Python project is checking the development status on Pypi. There's no clear way to answer the same question for cargo crates.

So you're trying to determine if something is maintained? What does that have to do with stability? Every single change can be breaking, thus being incredibly unstable, yet it's still maintained.

In Rust, the convention is that crates with a version number of 1.0.0 or above are "stable".

( Note however that Cargo has special rules for deciding whether crates should be compatible. See Specifying Dependencies - The Cargo Book )

See also here:

Cargo bakes in the concept of Semantic Versioning, so make sure you follow some basic rules:

  • Before you reach 1.0.0, anything goes, but if you make breaking changes, increment the minor version. In Rust, breaking changes include adding fields to structs or variants to enums.
  • After 1.0.0, only make breaking changes when you increment the major version. Don’t break the build.
  • After 1.0.0, don’t add any new public API (no new pub anything) in patch-level versions. Always increment the minor version if you add any new pub structs, traits, fields, types, functions, methods or anything else.
  • Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

1 Like

I think it also needs to be said that there are many crates on crates . io which in practical terms ARE quite stable even though the major version number is zero. Ultimately it comes down to a human judgement, As an example I would cite crossbeam: or perhaps ( this may perhaps be controversial ).


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.