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/5927#issuecomment-962070229,https://api.github.com/repos/pydata/xarray/issues/5927,962070229,IC_kwDOAMm_X845WAbV,2448579,2021-11-05T17:12:42Z,2021-11-05T17:12:42Z,MEMBER,"These two discussions on the dask side are relevant:
https://github.com/dask/community/issues/199
https://github.com/dask/community/issues/200
Our changelog is relatively nice to read so it would be good to preserve that even with the automation.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958936760,https://api.github.com/repos/pydata/xarray/issues/5927,958936760,IC_kwDOAMm_X845KDa4,10194086,2021-11-03T11:19:37Z,2021-11-03T11:19:37Z,MEMBER,"If `stable` only points to the last release for rtd, we might be able to get rid of it altogether (https://docs.readthedocs.io/en/stable/versions.html):
> If your project has any tags or branches with a name following semantic versioning, we also create a stable version, tracking your most recent release. If you want a custom stable version, create either a tag or branch in your project with that name.
","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958669947,https://api.github.com/repos/pydata/xarray/issues/5927,958669947,IC_kwDOAMm_X845JCR7,1217238,2021-11-03T05:45:58Z,2021-11-03T05:45:58Z,MEMBER,"I'm all for making the release process as automated and regular as
possible. This is definitely a better dynamic for contributors. Calendar
based versioning would also probably be more appropriate.
On Tue, Nov 2, 2021 at 6:14 PM Maximilian Roos ***@***.***>
wrote:
> Agree that stable can always point to the latest release!
>
> —
> You are receiving this because you are on a team that was mentioned.
> Reply to this email directly, view it on GitHub
> , or
> unsubscribe
>
> .
>
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958583164,https://api.github.com/repos/pydata/xarray/issues/5927,958583164,IC_kwDOAMm_X845ItF8,5635139,2021-11-03T01:14:03Z,2021-11-03T01:14:03Z,MEMBER,Agree that `stable` can always point to the latest release!,"{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958175626,https://api.github.com/repos/pydata/xarray/issues/5927,958175626,IC_kwDOAMm_X845HJmK,13301940,2021-11-02T21:20:53Z,2021-11-02T21:21:26Z,MEMBER,"> We could potentially still automate
> ""add new section to the whats-new.rst"",
> ""update the stable branch"",
> ""update the active version of the docs"" (maybe?), and
> ""email various mailing lists"".
with more frequent releases, will we still need to maintain the ""stable"" branch? It's my understanding that the ""stable"" branch is slightly different from the latest tag due to very few, trivial/doc changes that are added between releases. Without this additional branch, we would have one less thing to automate.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958123994,https://api.github.com/repos/pydata/xarray/issues/5927,958123994,IC_kwDOAMm_X845G8_a,14371165,2021-11-02T20:01:57Z,2021-11-02T20:01:57Z,MEMBER,"> I don't have a particularly strong view on more frequent releases — they seem a bit better — maybe contributors are more likely to contribute if they can use their code in a public release soon.
It's a joy contributing to Dask for me because of this, after merge you'll likely see your edit in a proper release the coming week. ","{""total_count"": 2, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958114423,https://api.github.com/repos/pydata/xarray/issues/5927,958114423,IC_kwDOAMm_X845G6p3,5635139,2021-11-02T19:47:10Z,2021-11-02T19:47:10Z,MEMBER,"> I quite like this idea in particular. I guess we also need to decide if we are okay with any release being fully automated though.
Maybe this is a confession — but when I do releases I'm not really adding any judgement. CI needs to pass but otherwise I'm not sure I'm adding any value beyond button-pressing...","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958110495,https://api.github.com/repos/pydata/xarray/issues/5927,958110495,IC_kwDOAMm_X845G5sf,35968931,2021-11-02T19:41:19Z,2021-11-02T19:41:19Z,MEMBER,"Thanks Max.
> One idea if we want to do very frequent releases is to write quality release notes a bit less frequently — i.e. ""here are some of the big things that we've added over the past three months"" — and then a bi-weekly release is automatically generated with less fanfare.
I quite like this idea in particular. I guess we also need to decide if we are okay with any release being fully automated though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958106835,https://api.github.com/repos/pydata/xarray/issues/5927,958106835,IC_kwDOAMm_X845G4zT,5635139,2021-11-02T19:36:15Z,2021-11-02T19:36:15Z,MEMBER,"I very much agree! To signal boost:
- Lowering the cost of doing releases! Whatever frequency we want to do releases, this is beneficial. And if people think we should do more frequent releases, then it becomes even more important. I haven't been able to spend enough time on xarray recently, but I've tried to add a bit more automation on each go (as have many others!).
- Not waiting for anything for a release. If it's ready then great; if not then another is arriving soon.
- The only reasons I could see for waiting are a) features are insufficiently independent and b) it's a ""call to action"" that gives people a prod to get something finished. I've rarely seen (a) here, though I can sometimes empathize with (b)...
I don't have a particularly strong view on more frequent releases — they seem a bit better — maybe contributors are more likely to contribute if they can use their code in a public release soon. (Though maybe it's possible to do numbered alpha / beta releases to PyPI so it's possible to use them immediately)
One idea if we want to do very frequent releases is to write quality release notes a bit less frequently — i.e. ""here are some of the big things that we've added over the past three months"" — and then a bi-weekly release is automatically generated with less fanfare.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334
https://github.com/pydata/xarray/issues/5927#issuecomment-958015953,https://api.github.com/repos/pydata/xarray/issues/5927,958015953,IC_kwDOAMm_X845GinR,13301940,2021-11-02T18:24:20Z,2021-11-02T18:24:20Z,MEMBER,"👍🏽 for frequent releases... With more frequent releases, should we switch to _calendar versioning_? I remember seeing this discussion in one of the issues but I don't recall what the conclusion was.
","{""total_count"": 2, ""+1"": 1, ""-1"": 1, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1042652334