Release v0.8.0

[JessicaS11]

Setting up for v0.8.0. We've got a bunch of new features already integrated, and a few more in the pipeline. Happy for suggestions on whether we should wait for more of the new things or plan on a few releases in the next couple months.

EDIT: we're going to release v0.8.0, with the planned release of v1.0.0 this fall once cloud read and argo data access via QUEST are implemented. If you're interested in helping prepare a release statement and/or advertising v1.0.0, we'd welcome your involvement!

[github-actions[bot]]

:point_left: Launch a binder notebook on this branch for commit 26e96e8ec37d9f613be7e41288b58015ac94f54c

I will automatically update this comment whenever this PR is modified

:point_left: Launch a binder notebook on this branch for commit 9d58250de7d55e3398c47ddd7ca70e705600ab46

:point_left: Launch a binder notebook on this branch for commit 7196f1834693ef676864a0124026a011e7e1404e

:point_left: Launch a binder notebook on this branch for commit ecf60276627164700465a7e63e9faab832d44684

:point_left: Launch a binder notebook on this branch for commit 5b6eb84c6b5c146650efcd32ab06e76267c8c52f

:point_left: Launch a binder notebook on this branch for commit 2e0d045eccd1dca07bcb82f07fa3bf17066ac5cc

:point_left: Launch a binder notebook on this branch for commit dba38b91433827b2925148c358889b6aa6c241f3

[rwegener2]

I just googled this ^(previous comment). If we were merging directly (without a PR) it seems pretty straightforward. But since we want to have a PR it gets a half step trickier. I think the options are either to:

1. revert the pr. seems pretty straightforward
2. create a new branch off of development from the commit we want and merge that into release

Option 1 seems the smoothest from my bit of reading. Both are effort, though. I'm happy to help do the monkeying around, if that's what we want. @JessicaS11 I'll defer to you if you think doing this is worth it in order to not make a breaking change to catalog. A 3rd option would be to put in a really quick PR that just adds a DepreciationError for that argument.

[JessicaS11]

@rwegener2 it sounds like option 3 (a quick PR to add a DeprecationError) is the cleanest approach to not have to monkey with reverting PRs.

Note I just updated the release branch to merge in #445.

[rwegener2]

446 has been created which adds the Depreciation Error for catalog

[JessicaS11]

I just approved #446. After you merge could you add it to the release log here?

I'm not sure why the Travis tests started failing, but it looks like a bunch of the viz ones again so we may just need to comment them out if it's not simple size mismatch updates. They seem to go through phases of working...

[rwegener2]

merged and added as a release ✅

The fact that the viz tests seem to ephemerally pass/fail is frustrating. Commenting them seems like a good idea for now, and also creating a ticket to document anything we know about the issue so it can be revisited in depth at another time.

[JessicaS11]

also creating a ticket to document anything we know about the issue so it can be revisited in depth at another time.

Good call - we've definitely had a few issues in this vein (I think I just finally got them all closed this spring!). If you're able to merge this today and then open a PR for merging dev into main, I can approve and tag the release so it can get through conda-forge before I go completely offline later today/tomorrow am.