Release frequency

[TomNicholas]

In issuing the last 2 xarray releases, I've noticed a pattern, that goes something like this:

1. We don't have a release for 3+ months, for no particular reason.
2. Someone realises they want a release, to fix a bug or make a new feature available.
3. That person announces that they would like a release.
4. Lots of people (myself especially) suggest all sorts of unfinished issues that they think could or should go into that next release.
5. The dev team end up spending the better part of a week trying to finish up all of these miscellaneous PRs.
6. Finally it is deemed "ready" in some fairly arbitrary way.
7. The release is made manually using the "16 easy steps".
8. No-one wants to think about releasing again for another 3 months...

Frequency

I mentioned this to @rabernat and he suggested that we should be releasing much more frequently.

If we released more regularly then we wouldn't have this effect of "oh and we should try to squeeze XYZ into this release".

I think the majority of the time xarray's CI is passing, and even when it's not it's only 1 tiny fix away from passing. That means that we in theory could release the main branch at practically any time, and it would be perfectly stable for users. (I personally exclusively use the most recent version of main.)

I also don't know of any downside to releasing very regularly (other than that someone has to issue the release).

How about we try to release after each of the bi-weekly dev calls? We could make it an official part of the call to end by saying:

• "any reason why we can't release right now?"
• "no, CI is passing"
• "okay [person] volunteers to click the button right after this meeting"

That would immediately increase our release frequency by up to 6x.

Automation

Can we automate any more steps of our release process? As far as I can tell the only steps that really need human intervention are

• "write the release summary" and
• "check that all the automated stuff went as expected".

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

@pydata/xarray thoughts?

[andersy005]

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

[max-sixty]

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.

[TomNicholas]

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.

[max-sixty]

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

[dopplershift]

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.

[Illviljan]

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.

[andersy005]

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.

[max-sixty]

Agree that stable can always point to the latest release!

[shoyer]

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 <#5927 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJJFVTVTJG5G3Q3CBIGGTDUKCLHPANCNFSM5HHB66HQ> .

[mathause]

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.

[dcherian]

These two discussions on the dask side are relevant:

dask/community#199
dask/community#200

Our changelog is relatively nice to read so it would be good to preserve that even with the automation.

[dcherian]

We've become good at monthly releases!