Thanks for writing this up, Neal. I think this is a pragmatic solution and I support this approach.
The only risk I see is that there may be a temptation to use this for more than bug fixes and as a way to bypass the official release process but I think the committers just need to be careful about managing that. Andy. On Wed, Feb 24, 2021 at 3:03 PM Neal Richardson <neal.p.richard...@gmail.com> wrote: > 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 >
