I am also supportive of Neil's proposal -- thank you for writing it up. On Thu, Feb 25, 2021 at 3:35 AM Joris Van den Bossche < jorisvandenboss...@gmail.com> wrote:
> 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 > > >
