Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stable 1.0.x release of string-cache? #236

Open
dkg opened this issue Jan 6, 2020 · 8 comments
Open

stable 1.0.x release of string-cache? #236

dkg opened this issue Jan 6, 2020 · 8 comments

Comments

@dkg
Copy link

dkg commented Jan 6, 2020

i note that release 0.8 appears to be pretty stable for string_cache -- any chance we might consider the API to be stable, and signifying that with a semver 1.0.0 release?

@SimonSapin
Copy link
Member

Cargo treats 0.8, 0.9, 0.10 etc. the same as 1.0, 2.0, 3.0, etc. The the difference is only symbolic. Is this alone worth putting the ecosystem through another breaking change?

@jyn514
Copy link

jyn514 commented Feb 9, 2020

There is a difference between 0.8, 0.9, ... and 1.0, 2.0: cargo will automatically update 1.0 to 1.1, but will refuse to update 0.8 to 0.9. This makes it harder for users to upgrade and increases the number of people still on old versions.

Is this alone worth putting the ecosystem through another breaking change?

I'm not sure what you mean by this.

@SimonSapin
Copy link
Member

There is a difference between 0.8, 0.9, ... and 1.0, 2.0: cargo will automatically update 1.0 to 1.1, but will refuse to update 0.8 to 0.9.

… yes? And it’ll automatically update 0.9.1 to 0.9.2 and refuse to update 2.1.6 to 3.0.0. So?

This makes it harder for users to upgrade and increases the number of people still on old versions.

Difficulty doesn’t change if we do 0.8 then 0.9 then 0.10, compared to 1.0 then 2.0 then 3.0.

Is this alone worth putting the ecosystem through another breaking change?

I'm not sure what you mean by this.

Making a new version that Cargo won’t automatically upgrade to only makes worse the problem you mentioned of various users depending on mutually-incompatible versions of the library. This can cause larger binaries at best when an app gets multiple copies of the library, or type errors when trying to use different version together in public APIs.

I’d prefer to have a better reason to do this rather than only having a prettier-looking version number.

@robojumper
Copy link

I'd like to ask for a 0.8.1 or 0.9 release to publish #235, which makes the serde dependency optional but enabled-by-default. This should be 0.9 because someone could have used default-features = false while relying on serde support (even though string_cache 0.8.0 doesn't expose any other features).

Thanks in advance!

@mvtec-bergdolll
Copy link

mvtec-bergdolll commented Nov 10, 2020

@SimonSapin please consider a 0.8.1 or 0.9 release, I have something that is seriously bogged down by a transitive serde dependency, which you already fixed with #235 11 Month ago, but haven't released. Is there any technical reason this can't be done?

@Ygg01
Copy link
Contributor

Ygg01 commented Nov 18, 2020

@SimonSapin I second bergdolll and robojumper. Release a 0.9would be enough for now. With stabilization a major milestone.

@SimonSapin
Copy link
Member

https://crates.io/crates/string-cache/0.8.1 is up and includes #235. Breakage is indeed possible with default-features = false, but I don’t know if there’s consensus that this should be covered by (cargo-modified) semantic versioning. And if you have an application with multiple dependencies that depend on string-cache, migrating everything to 0.9 would create busywork.

@dkg and @Ygg01, what do you mean by stable? I feel it could mean either "causes crashes" or "changes a lot", but neither really applies to string-cache in my opinion. 1.0 v.s. 0.x is all about communicating a certain image to potential users. If there is no other breaking change, image alone does not seem worth releasing a semver-incompatible version to me.

@Ygg01
Copy link
Contributor

Ygg01 commented Nov 23, 2020

Seems good enough for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants