Hi all, Any feedback on this? I'm building a release right now, and honestly I'm feeling quite burnt out about all the time-consuming and error-prone manual steps involved -- which are almost the exact same time-consuming and error-prone manual steps we've had for quite some time. I'd be very willing to put substantial effort towards the steps I proposed above. If you have a different idea for how to approach the automation, please let me know and I'd be very happy to help with a different approach. But I can't support the status quo: it uses far more of our community's precious time than it should, and it's far too easy to make a small mistake and create a bad release, and I've had enough of that. Thanks for your consideration, -Jane El jue, 3 abr 2025 a la(s) 8:00 a.m., Jane Sandberg (sandbergja@gmail.com) escribió:
Hi Evergreeners,
Throwing out a release process idea for your feedback: what if we had github actions build tarballs on each commit (using make_release in build-only mode)?
In my imagination: the release process would be much the same as it is today until the make_release step. The builder would generate the upgrade script and bump version numbers as they do today, then push those changes. This push would trigger github actions to build the tarball, so the builder wouldn't have to.
As I see it: * this would free us up from any issues and inconsistencies in the tarballs that result from folks' different environments and/or unclear instructions. * folks could test the newest code from a tarball at any time * if you catch a mistake after you're done building, you could simply push the correction and wait for the robot to generate an adjusted tarball, rather than needing to spin up your environment again or coordinate with somebody else. * since make_release would be running *all* the time, we would be able to catch errors we introduce to that script early * this would be an incremental step towards yet more automation of the build/release process
I believe we'd need to expire those tarballs after a certain amount of time so we don't hit github storage limits.
What do you think?
Thanks,
-Jane