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

Bump all dependencies #810

Merged
merged 1 commit into from
Nov 28, 2020
Merged

Bump all dependencies #810

merged 1 commit into from
Nov 28, 2020

Conversation

Eijebong
Copy link
Contributor

@Eijebong Eijebong commented Apr 25, 2020

  • Update blas-src to 0.6
  • Update itertools to 0.9
  • Update openblas-src to 0.9

Fixes #765

* Update blas-src to 0.6
* Update itertools to 0.9
* Update openblas-src to 0.9
@bluss bluss added this to the 0.14.0 milestone Apr 25, 2020
@termoshtt
Copy link
Member

@ZuseZ4 ZuseZ4 mentioned this pull request Oct 8, 2020
@nilgoyette
Copy link
Collaborator

With rayon, num-complex, approx + the three above, this PR is obsolete. What's the procedure? Replace this PR with another or nicely ask @Eijebong to update?

@cjordan
Copy link

cjordan commented Nov 23, 2020

Can I chime in naively - I forked ndarray just so I could bump its num-complex dependency, as another dependency was already using num-complex 0.3.0 and the different version apparently means that cargo refused to compile my project. So, is there any huge reason why ndarray should be restricted to 0.2.* or 0.3.*? Could it just be 0.* instead? I've noticed a similar problem for rayon. In both cases, I did not see an API change so everything just worked fine.

EDIT: GitHub formatting.

@ZuseZ4
Copy link
Contributor

ZuseZ4 commented Nov 26, 2020

@cjordan
https://semver.org/

From what I know, specifying a dependency like done here (a.b.) assures, that the project will always compile correctly.
By only specifying the major version a.
.* you may end up in a situation where one of your dependencies adds a pub function (or anything else) that you already implement in your own library. Cargo will pull the newest version that you allow. This might lead to nasty bugs where the runtime behavior silently changes, since the compiler adds the new implementation from your dependency, instead of your own one which has been used before.
Of course that's an unlucky situation and mostly won't happen, but the idea is to generally avoid such pitfalls by specifying the minor version too.
Please feel free to correct what I wrote in case that I got something wrong.

@mulimoen
Copy link

@ZuseZ4 You would only run into this problem when using glob imports, and this would be a compile time error at worst. You would not avoid this by specifying the minor version, this would simply mean all versions >=major.minor would be compatible with this crate, and minor bumps are allowed to add new functions.

@cjordan One has to specify major (or 0.minor) to publish a crate

ndarray could use the bound >=0.2.0, <0.4.0 for num-complex to allow either major version of num-complex if we require backwards compatability.

@bluss
Copy link
Member

bluss commented Nov 27, 2020

I would encourage a release to be made with dep update - I know I'm late to do it, but I will, if nobody else has time.

@xd009642
Copy link
Contributor

@bluss yeah I'd like a release with what we currently have, a dependency update and also these small PRs to go in 😄

If you have time to look at ndarray that would be grand 😁

@bluss
Copy link
Member

bluss commented Nov 28, 2020

Excellent @xd009642

@bluss bluss merged commit 76c8a95 into rust-ndarray:master Nov 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bump blas to 0.4.0
8 participants