You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there something conceptually wrong with linking bugfix release with each bug fix PR? Have the bug label do everything, kind of like the meeseeks backports.
A bugfix release with each PR is a little too much. While the release itself might be automated, there is still human overhead in communication and post-release activities. Also, I am not sure if it helps downstream maintainers to have to look out for a new bug fix release several times a week.
Note that @astrofrog implemented part of this - at least for pyerfa all one has to do is push the relevant tag and the rest is automatic. Or do we have that already for astropy too?
there is still human overhead in communication and post-release activities
Boooo, automate it all!!
I think once per PR is probably too much, but getting it to the point where it's basically a human checked cron job (monthly or even weekly?!) should be the goal imo.
@astrofrog , let's move the automated bugfix release convo here since is astropy/astropy-project#430 is about collecting Coordination Meeting discussion topics in general.
I have been hacking and testing more automated releases on my dkist package. The workflow I have settled on currently (there's still room for more automation) is this:
To be clear, I don't have any asks - just think it would be interesting to discuss. It would just be worth exploring whether we could make bugfix releases almost completely automatic, so we don't have to think too much about it. To go one step further than what @Cadair is suggesting, we could make it so that at periodic intervals (e.g. every week or every two weeks), a PR is automatically opened to render the changelog, and after a manual review (just to make sure everything is ok) we could merge it and this would automatically trigger a bugfix release. So this would be truly 'one-click' (unless there are issues in the changelog to fix, but these should usually be trivial).
If we want to go this route, what about having integration-testing to run against the bugfix RC also, just in case one of the bug fixes break downstream? It won't be the first time we thought we fixed a bug, but someone downstream was treating the bug as a feature, or when we unintentionally broke API/behavior compatibility.
That sounds like a good idea, but feels orthogonal? Do we do that on every bugfix manually at the moment?
Having a "downstream" workflow like gwcs / asdf etc would be a good way of doing that though. We could at least cover coordinated packages (+ sunpy 😉 ) that way?
Yes, I think you are right. When I have time, I can see if I already opened an issue about this somewhere, and if not, put some words together and open one... unless someone beats me to it. Update: astropy/astropy-integration-testing#25
Activity
Cadair commentedon Feb 24, 2022
Automate away those pesky bugfixes.
nstarman commentedon Mar 7, 2022
Is there something conceptually wrong with linking bugfix release with each bug fix PR? Have the
buglabel do everything, kind of like the meeseeks backports.pllim commentedon Mar 7, 2022
A bugfix release with each PR is a little too much. While the release itself might be automated, there is still human overhead in communication and post-release activities. Also, I am not sure if it helps downstream maintainers to have to look out for a new bug fix release several times a week.
mhvk commentedon Mar 7, 2022
Note that @astrofrog implemented part of this - at least for
pyerfaall one has to do is push the relevant tag and the rest is automatic. Or do we have that already for astropy too?astrofrog commentedon Mar 7, 2022
We already have that for astropy but there are a few steps before/after that are manual.
Cadair commentedon Mar 14, 2022
Boooo, automate it all!!
I think once per PR is probably too much, but getting it to the point where it's basically a human checked cron job (monthly or even weekly?!) should be the goal imo.
pllim commentedon Feb 10, 2025
pllim commentedon Feb 24, 2025
Re astropy/astropy-project#430 (comment)
@astrofrog , let's move the automated bugfix release convo here since is astropy/astropy-project#430 is about collecting Coordination Meeting discussion topics in general.
Is your specific ask to split https://github.com/astropy/astropy/blob/main/.github/workflows/publish.yml into 2 workflows: 1 for major release that needs human, and 1 for fully automated bugfix release as a
scheduledevent?Cadair commentedon Feb 25, 2025
I have been hacking and testing more automated releases on my
dkistpackage. The workflow I have settled on currently (there's still room for more automation) is this:astrofrog commentedon Feb 25, 2025
To be clear, I don't have any asks - just think it would be interesting to discuss. It would just be worth exploring whether we could make bugfix releases almost completely automatic, so we don't have to think too much about it. To go one step further than what @Cadair is suggesting, we could make it so that at periodic intervals (e.g. every week or every two weeks), a PR is automatically opened to render the changelog, and after a manual review (just to make sure everything is ok) we could merge it and this would automatically trigger a bugfix release. So this would be truly 'one-click' (unless there are issues in the changelog to fix, but these should usually be trivial).
pllim commentedon Feb 25, 2025
If we want to go this route, what about having integration-testing to run against the bugfix RC also, just in case one of the bug fixes break downstream? It won't be the first time we thought we fixed a bug, but someone downstream was treating the bug as a feature, or when we unintentionally broke API/behavior compatibility.
Cadair commentedon Feb 25, 2025
That sounds like a good idea, but feels orthogonal? Do we do that on every bugfix manually at the moment?
Having a "downstream" workflow like gwcs / asdf etc would be a good way of doing that though. We could at least cover coordinated packages (+ sunpy 😉 ) that way?
pllim commentedon Feb 25, 2025
I am just thinking that if it is automated, it is going to happen more often, but perhaps it is also orthogonal.
Cadair commentedon Feb 25, 2025
I think it would be a good thing to have a different issue for 😉
pllim commentedon Feb 26, 2025
Yes, I think you are right.
When I have time, I can see if I already opened an issue about this somewhere, and if not, put some words together and open one... unless someone beats me to it.Update: astropy/astropy-integration-testing#25