-
Notifications
You must be signed in to change notification settings - Fork 300
unpin matplotlib #2124
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
unpin matplotlib #2124
Conversation
|
No way it's that easy 😛 |
|
indeed :/ |
|
Going to start looking at the |
|
PR: #2127 |
|
Now looking at |
|
PR: #2128 |
|
Now working on datetime rounding errors. |
|
I am working on testCDL failures linked to ncdump output |
|
|
PR for datetime rounding errors: #2134 |
|
Now looking into PANDAS errors |
|
pandas PR: #2136 |
|
#2135 is a step into matplotlib check_graphic tests space |
|
#2139 has more check_graphic updates |
|
#2141 has a whole swathe of check_graphic removals, whilst attempting to maintain test coverage |
|
another PR related to pandas tests: #2142 |
|
@bjlittle tests rerunning |
|
Note that the datetime rounding errors fix (#2134) was moved to a cf_units change (SciTools/cf-units#66). |
|
I have proposed a different approach for dealing with the failing graphics tests, which is captured in #2150. |
|
Outstanding test failures, as of
|
|
So how imminent is 1.11? I ask because I basically cannot build 1.10 with tests because of all of the above compatibility issues with the latest packages. I'd vote for there to be a release as soon as these compatibility issues are corrected, without regard to any other outstanding features, whether that be 1.10.1 or 1.11.0. |
Same story here. A release needs to happen, ideally in the next 10 days, that can be said to support newer dependency versions (i.e. can be tested with them). Looking at the changes that are coming out of the woodwork, it is a healthier thing to call it v1.11 than v1.10.1 IMO (there are some behaviour changes needed). We are fortunate in that there is no social/political drive to release a v1.10.1 vs v1.11, so let's call a duck a duck and aim for You are right to be concerned (in another comment) by the time it took to get v1.10 out. My sole aspiration for v1.11 is to be able to claim "support" for unpinned dependency versions, and anything else represents a distraction from this extremely important aim. I have updated the v1.11 milestone with some dates, as well as a clear goal - as a group, we need to learn the lesson of release little and often and it is my hope that we are turning the corner in that direction. Ping @SciTools/iris-devs - please be aware once this PR is merged, we will be extremely close to releasing Iris v1.11. |
Sounds like a good plan. There are/will be some commits on v1.10.x that need to be merged into master before cutting v1.11.x branch, just a heads up so we can avoid a headache. |
|
as easy as six weeks hard labour /me points at a travis green tick \o/ |
|
@marqh Really, really? 😲 |
|
@bjlittle Don't be asking that question Bill, especially not twice. If the big green tick says it's OK, then it must be OK. |
|
@marqh and @corinnebosley whoop! 🎉 😄 |
No description provided.