Closed borupdaniel closed 4 years ago
I would actually prefer to call this v2.0.3 but I'm not sure whether it's reasonable to call adding Matplotlib3 compatibility a "bug fix". Thoughts?
Thanks for fixing Matplotlib 3. It will be nice to be able to remove that constraint from the conda-forge recipe!
I haven't tried running it yet with these change, but they look good to me. Have you tested whether compatibility with Matplotlib 2.x is preserved?
I don't have a strong opinion either way on the version number. I don't think it is unreasonable to classify fixing compatibility for recent matplotlib as a bug. However, if these changes break anything for Matplotlib 2.x then 2.1 is probably more appropriate.
@grlee77 your debugging on Thursday was a big help, so thanks to you as well!
I just gave this a try with Matplotlib 2.1.2 and it seems to work fine, so this shouldn't break anything or force a matplotlib update for anyone. With that in mind it seems like just bumping the patch number is ok.
Roadmap-wise, what I have in mind is that v2.1 will add the C++ nodes back in for native windows, while v3.0 (less clearly) will come when we spin off the more MRI-centric nodes here into their own library.
This PR will be v2.1.0 for the core nodes. The main change is addition of compatibility for Matplotlib 3, which is a fairly minor (but helpful) change going forward.
Other minor changes include removing the test networks — they're now in the feedstock repository since 1) their main function is testing at build time and 2) we should be able to change them without necessitating a new version of the core nodes.
In addition, I have added a couple of new files describing which nodes are unix-only for now (due to C dependencies) and some python libraries we may want to incorporate in the future.