Hi Cole, Thanks for looking into the ATR process! I agree it's a good opportunity with our upcoming release plans to give it try.
As you also raised, we are shaping up for another Beta release with the open feature PRs, as well as some bug fixes on the 3.7/3.8 branches. So I'd like to propose that we begin code freeze for these 3 releases towards the end of this week, as the committers finish reviews on them. Cheers, Yang On 2026/10/29 22:09:59 Cole Greer wrote: > Hi everyone, > > I wanted to suggest that we start planning for the next set of releases > to occur roughly in late November. We are about due for our next set of > 3.7/3.8 releases, and I think it's a good time for a 4.0.0-beta.4 as well. > > I also wanted to propose migrating our release process to utilize the > new Apache Trusted Releases (ATR) tooling, which recently entered beta. > It may be a little early to fully migrate our releases onto ATR, but I > think using it for our own TP4 betas is a good opportunity to test it > out begin developing a more modern release process. > > For anyone unfamiliar with ATR, its main value from my perspective is > the automation of the staging and releasing of our SVN artifacts in > preparation of the vote and during deployment. For our purposes, the > code freeze and pre-flight check would be mostly unchanged, the vote > preparation phase would retain the Nexus staging steps, but the SVN > artifact signing and staging would be managed by ATR. The vote itself > would also be run via ATR, although the release manager would still be > responsible for the final tally. ATR also enforces a lot of pre-vote > checks for things like signatures, license/notice compliance... which > would reduce our dependence on validate-distribution.sh. Post-vote, the > release manager would still be responsible for deploying convenience > binaries to maven central, dockerhub, PyPi... (each of these would be > recorded in ATR for future reference), and ATR would manage the release > of the SVN dist/ artifacts. > > Unless there are any objections, I would like to experiment with > conducting the 4.0.0-beta.4 release using an ATR-based process, although > I would retain the existing process as a fall-back in the case of any > blockers arising. > > Long-term, I would like to further automate the release process, such > that the whole process from pre-flight check to the vote thread can be > run via CI. ATR is a useful step in that direction, however the biggest > blocker is ensuring our build is fully reproducible, which would allow > us to validate release artifacts which have been prepared on untrusted > hardware. I'd like to experiment with that long-term, but it's beyond > the scope of what I want to try in this next release cycle. > > Please let me know if you have any thoughts or concerns regarding any of > this. > > Thanks, > > Cole > >
