Skip to content

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

Closed
effigies opened this issue Nov 3, 2015 · 3 comments
Closed

Bug fix release #373

effigies opened this issue Nov 3, 2015 · 3 comments

Comments

@effigies
Copy link
Member

effigies commented Nov 3, 2015

#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?

@effigies
Copy link
Member Author

effigies commented Nov 3, 2015

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.

@matthew-brett
Copy link
Member

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?

@effigies
Copy link
Member Author

effigies commented Nov 6, 2015

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 master. But there's a bit of interleaving and trying to cherry-pick our way to a 2.0.2 might be a nightmare.

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.

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

2 participants