issue_comments

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.

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.

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 https://github.com/pydata/xarray/issues/5927#issuecomment-958583164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJJFVTVTJG5G3Q3CBIGGTDUKCLHPANCNFSM5HHB66HQ .

Agree that stable can always point to the latest release!

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.

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.

GitHub's new automated release notes may be of interest to some of this discussion. Essentially they allow you to provide a template to format the list of merged PRs on the branch since the last release.

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...

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.

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.

👍🏽 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.