# Highlights of 2023 for cargo-semver-checks _Published: 2024-01-16_ *2023 was a big year for `cargo-semver-checks`! We saw ecosystem-wide adoption in projects of all shapes and sizes: the [`tokio`](https://github.com/tokio-rs/tokio) and [`PyO3`](https://github.com/pyo3/pyo3) ecosystems, company-backed OSS projects from companies like [Amazon](https://github.com/awslabs/aws-sdk-rust) and [Google](https://github.com/google/zerocopy), and even in [`cargo` itself](https://github.com/rust-lang/cargo/blob/9d3473c727b776c165b03c3be26ae77c148474d6/.github/workflows/main.yml#L96-L102). Here's a look back at the highlights of 2023!* ![cargo-semver-checks banner showing a stylized Ferris carefully holding a crate in its pincers.](/blog/2024-01-16-highlights-of-2023-for-cargo-semver-checks/logo-for-light-bg.png) *`cargo-semver-checks`' new logo, courtesy of [NUMI](https://github.com/numi-hq/open-design)'s program offering free design services for open-source projects 💖 Inspired by the [international handle with care symbol](https://packmojo.com/blog/the-complete-guide-to-international-packing-symbols/#handle-with-care), our logo shows Ferris carefully inspecting a crate.* Dark mode variant: [image](/blog/2024-01-16-highlights-of-2023-for-cargo-semver-checks/logo-for-dark-bg.png). `cargo-semver-checks` saw massive improvements in 2023. Here are my three favorites, in chronological order: - The linter became [up to 2300x faster thanks to query engine optimizations](/blog/2023-02-07-speeding-up-rust-semver-checking-by-over-2000x/). I gave a talk on this [at P99 CONF](https://www.youtube.com/watch?v=Fqo8r4bInsk). - A study of Rust's 1000 most popular crates revealed that [more than 1-in-6 has accidentally violated semver](/blog/2023-09-07-semver-violations-are-common-better-tooling-is-the-answer/), demonstrating that semver breakage happens to everyone and is not due to a lack of effort or skill. Only tooling improvements can prevent semver breakage and the frustration that it produces.[^sn-1] - We eliminated over 60% of all false-positive lint errors encountered in practice. This included [handling the many edge cases caused by `#[doc(hidden)]` items](/blog/2023-11-18-checking-semver-for-doc-hidden-items/),[^sn-2] as well as many other bugs discovered while running `cargo-semver-checks` on 14000+ Rust crate releases in the study mentioned above. Finding and eliminating those false-positives was _directly enabled_ by the earlier performance improvements, which I find aesthetically pleasing. We wouldn't have had a good sense of those bugs without running the ecosystem-wide semver study, and the study would have been impossible if it required 2000x as much CPU time as it did. If we couldn't discover and tackle these bugs _en masse_, then you — our users — would have had to report them as GitHub issues one at a time 😣 I'm very happy we avoided that! *Discuss this post on [r/rust](https://www.reddit.com/r/rust/comments/1988kdo/higlights_of_2023_for_cargosemverchecks/) or [lobste.rs](https://lobste.rs/s/o5o5oi/higlights_2023_for_cargo_semver_checks). [Subscribe to future posts](/subscribe/).* ## Now checking twice as many lints! During the course of 2023, `cargo-semver-checks` ~doubled its library of lints: from 30 lints at the beginning of the year to 57 lints by the end. That's 57 fewer ways a breaking change can sneak into our crates 🎉 The vast majority of new lints were contributed by _you_, our community! 🙇‍♂️ Writing new lints is the _easiest way to contribute_ to `cargo-semver-checks`: it only takes a few minutes to write a new lint! There are _hundreds_ of lints that still need to be written, so take a look at [our contributing guide](https://github.com/obi1kenobi/cargo-semver-checks/blob/main/CONTRIBUTING.md) and then [grab a lint from our issue tracker](https://github.com/obi1kenobi/cargo-semver-checks/issues?q=is%3Aissue+is%3Aopen+label%3AA-lint+label%3AE-help-wanted+label%3AE-mentor)! If most lints are community contributions, you might wonder what I do for the project. If you've ever worked on any kind of static analysis project, you'll know that "new lints take a few minutes to write" is not the natural state of such things. A lot of work has to happen for that to be the case — and for it to stay the case in the long run, even as our goals get ever loftier and our lints grow more and more complex. Most of this work happens outside of the main release-to-release spotlight, if not outright behind the scenes! Highlighting some of that work is why I write these blog posts 😁 ## `cargo-semver-checks` in talks and podcasts ![Slide with large text: 1 in 6 of the top 1000 crates have broken semver at least once. It wasn't their maintainers' fault, none of us would have fared any better.](/blog/2024-01-16-highlights-of-2023-for-cargo-semver-checks/breakage.png) *A slide from my meetup talks, describing the findings of [running `cargo-semver-checks` across a spectrum of Rust's most popular crates](/blog/2023-09-07-semver-violations-are-common-better-tooling-is-the-answer/).* In addition to [my performance-oriented talk at P99 CONF](https://www.youtube.com/watch?v=Fqo8r4bInsk) mentioned above, I also got a chance to talk about `cargo-semver-checks` at a few more events: - I was [a guest on the _RustShip_ podcast](https://hachyderm.io/@predrag/110939918768351877) where we dug into how `cargo-semver-checks` works under the hood, and how it came to exist. - On the [_Sustain_ podcast](https://podcast.sustainoss.org/178), we talked about how open-source projects like `cargo-semver-checks` are a great opportunity for [talent discovery and mentorship](https://hachyderm.io/@predrag/110427313794115571). - On the [_Software Unscripted_ podcast](https://podbay.fm/p/software-unscripted/e/1694480100), we chatted about the surprising complexity semver inflicts on both library maintainers and the maintainers of package managers. - I gave talks at the [Rust NYC](https://www.meetup.com/rust-nyc/events/294123104/) and [Rust Dublin](https://www.meetup.com/rust-dublin/events/296346693/) meetups, which were a wonderful way to meet more people in the Rust community. Big thanks to all the hosts and organizers of these events — they were a ton of fun 💖 If there's a podcast, meetup, conference, or other event where you think my work on `cargo-semver-checks` could be a good fit, please [let me know](https://hachyderm.io/@predrag)! ## A sneak peek at what lies ahead My next post will cover the `cargo-semver-checks` plans for 2024. But we've already had some good progress in the first couple of weeks of 2024! Here's a sneak peek. Starting with our next release, [semver lints will run in parallel](https://github.com/obi1kenobi/cargo-semver-checks/issues/621)! Conceptually, I've previously described `cargo-semver-checks` as ["a for-loop over a list of lint queries."](/blog/2022-12-23-cargo-semver-checks-today-and-in-2023/) Now, that's becoming a parallel for-loop using `rayon`! This produces a ~3x linting time speedup on the default GitHub Actions runner, and much more on beefier hardware.[^sn-3] Our architecture choices laid the groundwork for this change a long time ago, and [a community-contributed PR](https://github.com/obi1kenobi/cargo-semver-checks/pull/625) took it to the finish line 🙏 Come back for the next post to read about the remaining plans for `cargo-semver-checks` in 2024. If you'd like, [subscribe over RSS](https://predr.ag/atom.xml) or [get my posts in your inbox](/subscribe/). ## How you can help `cargo-semver-checks` All these developments were made possible by the individuals and companies who sponsor my work via [GitHub Sponsors](https://github.com/sponsors/obi1kenobi/). Thank you so much! ♥ Funding is the top factor that determines whether open-source projects like `cargo-semver-checks` survive or become abandoned. I love working on `cargo-semver-checks`, but right now I can't pay my rent with it! That puts a hard cap on how many hours I can afford to work on it each week. I could use your help! If your employer uses `cargo-semver-checks`, please speak with them about sponsoring its development! If they are hesitant, ask what it would take to sponsor it? If they aren't comfortable sponsoring _in general_, ask if they'd be open to sponsoring a particular feature or use case that you wish it supported. Just _ask_! That 10 minute conversation with your manager will make all the difference for me and `cargo-semver-checks`. If you aren't sure how to approach that conversation, or if your company has a process you aren't sure how to navigate, please [reach out over social media](https://predr.ag/subscribe/) — let's chat. *Discuss this post on [r/rust](https://www.reddit.com/r/rust/comments/1988kdo/higlights_of_2023_for_cargosemverchecks/) or [lobste.rs](https://lobste.rs/s/o5o5oi/higlights_2023_for_cargo_semver_checks). [Subscribe to future posts](/subscribe/).* [^sn-1]: This was joint work with [four other folks who used it as part of their bachelors' thesis project](https://arxiv.org/abs/2308.14623). I'm particularly proud of how thoroughly we proved that the semver-breakage we found was _real_ and not false-positive. For each breaking change, we generated a Rust program and asserted that it compiles fine on the older version but is indeed broken by the new release. And this was _just one_ of [our validation steps](https://predr.ag/blog/semver-violations-are-common-better-tooling-is-the-answer/#detailed-results-how-we-validated-them)! [^sn-2]: Joint work with [David Hewitt](https://twitter.com/__davidhewitt__), one of the maintainers of the awesome [PyO3 crate](https://github.com/pyo3/pyo3). [^sn-3]: This speedup number is only for the portion of runtime required to _run_ the lints, not total wall-clock time. As a rule of thumb, rustdoc generation used to be 50-70% of our total wall-clock runtime prior to this work, and the rest was lint execution time. Speedups in lint execution are always lovely and welcome, but are subject to diminishing returns due to [Amdahl's law](https://en.wikipedia.org/wiki/Amdahl%27s_law) — rustdoc's runtime is [the long pole](https://devblogs.microsoft.com/oldnewthing/20080805-00/) in the performance graph. Rustdoc maintainers are well aware of this, and are working on it! Copyright (C) Predrag Gruevski 2024. [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.en)