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

Reply via email to