html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/2928#issuecomment-510939525,https://api.github.com/repos/pydata/xarray/issues/2928,510939525,MDEyOklzc3VlQ29tbWVudDUxMDkzOTUyNQ==,691772,2019-07-12T15:56:28Z,2019-07-12T15:56:28Z,CONTRIBUTOR,"Fixed in 714ae8661a829d.

(Sorry for the delay... I actually prepared a PR but never finished it completely even it was such a simple thing.)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,438389323
https://github.com/pydata/xarray/issues/2928#issuecomment-487782633,https://api.github.com/repos/pydata/xarray/issues/2928,487782633,MDEyOklzc3VlQ29tbWVudDQ4Nzc4MjYzMw==,1217238,2019-04-29T23:52:25Z,2019-04-29T23:52:25Z,MEMBER,"> The thing I don't really understand and why I wanted to ask first: is there a clear paradigm about compatibility in the pydata universe? Despite its 0.x version number, I guess xarray tries to stay backward compatible regarding its public interface, right? When are the versions of dependencies increase? Simply motivated by need of new features in one of the dependent libraries?

The usual rule of thumb is to keep things working for *at least* one ""major"" release with a deprecation warning, so that somebody who continuously runs their code has time to notice before things break.

The exact appropriate time to wait is project dependent. In xarray's case, we've usually been waiting 6-12 months before making breaking changes. NumPy might wait 2-3 years.

There isn't a strict rule for bumping required dependency versions, but again it's motivated by a desire to give users some flexibility so as not to require them to upgrade everything at once.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,438389323
https://github.com/pydata/xarray/issues/2928#issuecomment-487759590,https://api.github.com/repos/pydata/xarray/issues/2928,487759590,MDEyOklzc3VlQ29tbWVudDQ4Nzc1OTU5MA==,691772,2019-04-29T22:00:58Z,2019-04-29T22:00:58Z,CONTRIBUTOR,"> Any interest in putting together a PR?

Yes, can do so. When writing the report, I actually thought maybe preparing a PR is easier to write and to read than the ticket... :) In this case it really shouldn't be a big deal fixing it.

Maybe a bit off-topic: The thing I don't really understand and why I wanted to ask first: is there a clear paradigm about compatibility in the pydata universe? Despite its 0.x version number, I guess xarray tries to stay backward compatible regarding its public interface, right? When are the versions of dependencies increase? Simply motivated by need of new features in one of the dependent libraries?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,438389323
https://github.com/pydata/xarray/issues/2928#issuecomment-487750028,https://api.github.com/repos/pydata/xarray/issues/2928,487750028,MDEyOklzc3VlQ29tbWVudDQ4Nzc1MDAyOA==,1217238,2019-04-29T21:26:03Z,2019-04-29T21:26:03Z,MEMBER,"> Not sure, can xarray break compatibility with dask <1.1.0 with some future version? Otherwise I guess there needs to be some legacy code in xarray which calls the right function.

Thanks for the report.

Yes, we can definitely do this in the future, but for now, I think we should try to be backwards compatible.

Using something like the following instead xarray should solve this:
```python
try:
    blockwise = dask.array.blockwise  # new name in dask 1.1
except AttributeError:
    blockwise = dask.array.atop
```

Any interest in putting together a PR?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,438389323