Skip to content

Commit

Permalink
Increment version to 0.4.0
Browse files Browse the repository at this point in the history
  • Loading branch information
@lpenz
lpenz committed Apr 2, 2023
1 parent d4c009b commit 1047b89
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion Cargo.toml
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
[package]
name = "tokio-process-stream"
description = "Simple crate that wraps a tokio::process into a tokio::stream"
version = "0.3.0"
version = "0.4.0"

This comment has been minimized.

Sign in to view

Copy link
@alexheretic

alexheretic Apr 2, 2023

Contributor

Hey @lpenz how come this was a breaking change? From a quick look it seems non-breaking so could have been 0.3.1?

I'm just checking as breaking bumps cause a little bit more manual effort downstream compared to non-breaking ones where a simple cargo update would handle it.

This comment has been minimized.

Sign in to view

Copy link
@lpenz

lpenz Apr 3, 2023

Author Owner

I usually do <unsafe to upgrade>.<unsafe to downgrade>.<safe both ways>
In this case, there's a new public function, so it's unsafe to downgrade - if the new function is used, your code stops compiling.
Isn't this just a matter of doing cargo upgrade --incompatible ?

This comment has been minimized.

Sign in to view

Copy link
@alexheretic

alexheretic Apr 4, 2023

Contributor

Hmm that's interesting, but not really consistent with how semver works in the rust ecosystem. It's really just about breaking and non-breaking. semver ignores leading 0. after that the first number denotes breaking-to-upgrade changes, any following numbers are non-breaking.

Downgrade safety isn't really part of this. Though i think your scheme is compatible just not with the leading 0.. With a non-zero major you have 2 kinds of non-breaking increment (I tend to see this used for minor=non-breaking new feature, patch=fix). cargo just interprets both as non-breaking bumps.

With zerover (which is appropriate for this crate) you can only express breaking or non-breaking. So for new public functions i would expect 0.3.0 -> 0.3.1 since no existing code will stop compiling (or break otherwise) after cargo update.

On a practical level when i see a breaking change like 0.4.0 it means i lookup changelogs to investigate what the break was and if i need to modify my usage. If no breaks affect my usage i can just update my crate. However if this is a lib crate and I've exposed public types i may also need to make a breaking release. So breaking changes spread much slower through the dependency chain and require much more work "churn". Non-breaking bumps freely upgrade even in long dependency chains.

Anyway sorry to go on and on. In this particular case it's not a huge deal, my usage is a single bin crate so i just updated it.
authors = ["Leandro Lisboa Penz <lpenz@lpenz.org>"]
edition = "2021"
license = "MIT"
Expand Down

0 comments on commit 1047b89

Please sign in to comment.