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

help
1

Hello,

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?
2

What exactly do you mean by "stable"?

1 Like
3

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.

4

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.

5

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.

https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field

2 Likes
6

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: https://crates.io/crates/crossbeam or perhaps https://crates.io/crates/rand ( this may perhaps be controversial ).

4 Likes
7

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.