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 > > > > > >
