Hi all, We've had some discussion about ways to reduce the cost of releasing and ways to allow maintainers of subprojects to make more frequent maintenance releases. Specifically, see these two recent mailing list threads:
* https://lists.apache.org/thread.html/rf43d270b4dde2dce601c69fdbb0ab9e741232149e6c8a24caa6ac0c8%40%3Cdev.arrow.apache.org%3E * https://lists.apache.org/thread.html/rda5ec60785a3d4f5cd763379813aa2b386af15eac2ba0567ade5ce9b%40%3Cdev.arrow.apache.org%3E Following up on our discussion on last week's sync call, I'd like to propose a solution that brings both threads together: let's keep the quarterly major release process as it is, with binary packages made as part of the release process and voted on together, and let's allow maintenance/patch releases in between major releases to be a vote only on a source (SHA of a commit on a maintenance branch/tag). That way, we can allow patch releases more easily, and only those languages with critical bug fixes need to worry with building and publishing binary artifacts. At the same time, we maintain our shared mapping between a GitHub tag/commit and a release number across subprojects and avoid the risk that (e.g.) Rust makes a 3.0.1 patch release on a custom maintenance branch with 5 commits, and Python makes a 3.0.1 patch release on a different branch with different commits included. Thoughts? Neal
