-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release frequency #5927
Comments
👍🏽 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. |
I very much agree! To signal boost:
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. |
Thanks Max.
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... |
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. |
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. |
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. |
Agree that |
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>
.
|
If
|
These two discussions on the dask side are relevant: dask/community#199 Our changelog is relatively nice to read so it would be good to preserve that even with the automation. |
We've become good at monthly releases! |
In issuing the last 2 xarray releases, I've noticed a pattern, that goes something like this:
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 ofmain
.)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:
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
We could potentially still automate
whats-new.rst
",@pydata/xarray thoughts?
The text was updated successfully, but these errors were encountered: