issue_comments: 844455537

This data as json

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/5298#issuecomment-844455537 https://api.github.com/repos/pydata/xarray/issues/5298 844455537 MDEyOklzc3VlQ29tbWVudDg0NDQ1NTUzNw== 13301940 2021-05-19T20:39:43Z 2021-05-19T20:39:43Z MEMBER

Glad to hear that releasing is getting easier/simpler :)

There are some smaller tasks we can put into pipelines if we want to squeeze more out there (e.g. updating stable branch, adding contributor lists). The only really necessary tasks are writing the summary, organizing the whatsnew, sending out communications.

I've been thinking about this, and I'm wondering if something like this great tool: github-activity could help us (at least with updating whatsnew.rst). github-activity is able to generate the changelog from the GitHub API. This would eliminate the need for updating whatsnew.rst multiple times (once for each PR). With proper labels, github-activity is able to categorize PRs and Issues during the changelog generation. Another cool feature of github-activity is that it includes other contributions in addition to the default PR submissions: https://github-activity.readthedocs.io/en/latest/#how-does-this-tool-define-contributions-in-the-reports

There's an extreme end of "constantly release new main branches". I don't see anything functionally wrong with that, but I'm sure there are unexplored consequences, and I'm not sure our role is to forge a new path in OSS release cycles.

I'm curious.. How are these "new main branches" different from git tags from releases?

So maybe monthly is a reasonable balance?

👍🏽 for frequent/monthly release cadence 

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   891200849