Breaking changes within patch release - 1.0.1

[DDtKey]

Firs of all, thank you for the maintenance!

Recently released version 1.0.1 included this PR: #48

Which changed public type, this is breaking change and broke some dependent crates (e.g pattern matching in atuin)

I'd suggest to yank the version and release major patch instead

[xpe]

I also found my way here because of the downstream breakage seen on atuin's issue tracker.

To expand on what @DDtKey wrote, see also:

• Stack Overflow: What exactly is considered a breaking change to a library crate?
• RFC 1105: API Evolution

For what it is worth, many of the things listed above are not obvious, at least not without quite a bit of forethought. We're all learning.

[maciejhirsz]

Argh, that's what happens when you merge things and then forget about doing a release for months on end. I'll fix that later today.

[xpe]

@maciejhirsz Thanks. This is also what sometimes happens you build a library that other people use. 😄

[ellie]

Thank you! Appreciate your work here btw ❤️

Otherwise, I'm going to take the opportunity to plug @obi1kenobi's https://github.com/obi1kenobi/cargo-semver-checks. He's spent a long time working on this problem and has produced some excellent tooling to try and catch it before it becomes an issue.

[obi1kenobi]

Thanks for the kind words, Ellie 😊

cargo-semver-checks isn't perfect yet, but it already has 90+ lints flagging various kinds of breakage. In this case, it wouldn't have caught the type change (obi1kenobi/cargo-semver-checks#149), but its enum_unit_variant_changed_kind lint would have caught the breaking change here in the ErrorKind::InvalidWord variant.

I'd be happy to answer any questions folks here might have!

[maciejhirsz]

Released 2.0.0, 1.0.1 got yanked. Thank you and apologies 🙏.

[ellie]

Thanks for the speedy fix!

[DDtKey]

Thank you @maciejhirsz! 🙏