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

Duplicate serde json features #138

Open
wants to merge 7 commits into
base: trunk
Choose a base branch
from

Conversation

alexanderkjall
Copy link

As can be seen here: https://docs.rs/crate/bigdecimal/0.4.5/features

There is one feature that is named serde-json and one that is named serde_json.

This is a tad confusing, so this pr uses the dep: syntax to remove one of them.

See here for documentation about the syntax: https://doc.rust-lang.org/cargo/reference/features.html#optional-dependencies

akubera and others added 7 commits July 5, 2023 02:20
* Fix issue where RUST_BIGDECIMAL_DEFAULT_PRECISION envvar would always
  trigger a rebuild

* Fix issue where .neg() could be called on {signed-int}::MIN values

* Add implementions of Add/Sub/Mul/Div for primitive values

* Use 'proptest' crate to improve arithmetic testing
@akubera
Copy link
Owner

akubera commented Oct 19, 2024

I'm aware but unfortunately that syntax was added after the Minimum Supported Rust Version (v1.43) of the 0.4.x version of this library (as can be seen from the failing tests). If there's another way around it I'd be curious but until then I'd prefer to wait until 0.5.0.

@alexanderkjall
Copy link
Author

yeah, I was aware that this would break MSRV, so it's understandable if you consider that a breaking change, I should have written something about it.

As far as I know there isn't any other way to exclude a feature, but I'm far from an expert in these things.

@alexanderkjall
Copy link
Author

I guess it's also a breaking change to remove a feature, since someone might use it.

@akubera
Copy link
Owner

akubera commented Oct 19, 2024

I think with "json_serde" things won't compile, so people can't make the mistake for long. But I think I will be removing the feature sometime in the future, though I am afraid it will break a lot of projects at this point. People really should be pinning the version to "0.4.x" to avoid such surprises, I won't break it until 0.5.0.

My thought process here is this numerical code shouldn't change much and I'd rather have very stable library which works with old compilers for reproducibility and constrained environment reasons. The only things I really miss in new versions is stabilized const functions, though cargo.toml compatibilities in dependencies are a pain too.

@alexanderkjall
Copy link
Author

It sounds wise to be very conservative in these types of crates :)

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

Successfully merging this pull request may close these issues.

2 participants