search

nipy / nibabel

Python package to access a cacophony of neuro-imaging file formats
http://nipy.org/nibabel/
Other
646 stars 257 forks source link

Bug fix release #373

Closed effigies closed 8 years ago

effigies commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.