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/pull/2571#issuecomment-443474646,https://api.github.com/repos/pydata/xarray/issues/2571,443474646,MDEyOklzc3VlQ29tbWVudDQ0MzQ3NDY0Ng==,6628425,2018-12-02T02:10:22Z,2018-12-02T02:10:22Z,MEMBER,"> It must also be noted that this might break some code in downstream libraries (including mine) which has built workarounds for this and will now error because the bounds are already decoded. Here also, I'm quite confident that this is an edge case but its worth mentioning. Should I put my what's new in ""Breaking changes"" instead?

I for sure see this perspective.  I also think a plausible case could be made that this change is like a ""bug fix,"" that is something that people may have needed to work around before in various ways, but ultimately should not have needed to.  So I think it's up to you what you think is best.  

If you do decide to shift it to the breaking changes section, I would suggest being a little more specific about under what circumstances the behavior is changing (i.e. this only impacts the behavior for time bounds variables defined via CF conventions that do not already have ""units"" and ""calendar"" attributes).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,384004189