Alright, there seems to be enough consensus around giving this a shot. Since this sounds like a procedural change, I'll start a [VOTE] thread.
Neal On Thu, Feb 25, 2021 at 9:36 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > I think we should give this a try and see how it works out. > > 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. > > Agree this is a concern, but at this point IIUC it is mostly theoretical. > My understanding is the intent is to only do patch releases and not minor > releases with this process. When we get to the point of doing minor > releases for libraries we should probably revisit this. > > On Thu, Feb 25, 2021 at 9:32 AM Andrew Lamb <al...@influxdata.com> wrote: > > > 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 > > > > > > > > > >
