On Wed, 24 Feb 2021 at 23:03, 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. > On the other hand, independent version numbers could also be desirable in certain cases? Assume that following this proposal Rust makes a minor 3.1.0 release, and then afterwards there is a Python regression we want to fix. The next available version then is 3.1.1, which means that for pyarrow the versioning goes from 3.0.0 to 3.1.1, which will also be confusing for users. > > Thoughts? > > Neal >
