-
Notifications
You must be signed in to change notification settings - Fork 262
Bug fix release #373
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
Comments
I suppose in that vein, does it make sense to mark nibabel 2.0.1 as requiring numpy <= 1.9? Package maintainers that add their own patches can ignore that, but if somebody is installing from pypi, there's nothing stopping them from breaking nibabel with a numpy upgrade. |
A release seems like a good idea. Were you thinking to release current master as 2.1, or apply the numpy 1.10 / Python 3.5 patches to 2.0.1 and release that as - say 2.0.2? |
That was basically my question: whether a 2.0.2 makes sense or if we should go ahead with 2.1... My feeling is that the bug fixes should be put into a 2.0.2 and 2.1 can wait on the Gifti code, since we've already started merging a number of relevant PRs into So if 2.0.2 is bug fixes, the following post-2.0.1 PRs are labelled as bug fixes: #325 #332 #336 #339 #340 #347 #358 #363 #369 Possibly there are some intermediate PRs or direct commits worth throwing in for simplicity. I'd probably avoid the massive PEP8 cleanup (#337) unless some later PR would be a mess to include without it. |
#370 shows there is at least one nibabel package maintainer supporting numpy 1.10 in the wild. Once #367 is in, I believe we'll have full Python 3.5 and numpy 1.10 support.
Does it make sense to have a bug fix release, or push on to 2.1 or 3.0?
The text was updated successfully, but these errors were encountered: