Hi, I agree with Jacob's proposal, and also share the concern with Kou. IMHO, it would be great to have several potential release managers. On some other Apache projects, we had a kind of release bottleneck with a very limited number of release managers. Maybe it would be interesting to have reviewers.yaml per component and the two first reviewers would be the "first release manager). Happy to help David on Java component if needed ;)
Another discussion (not in this thread) that it would be great to have is about release versioning. I'm a bit surprised that a lot of Arrow releases use major version whereas it doesn't contain any breaking change. For our users, it would be useful if a release really include breaking change (public API changes, spec changes, ...) or just fixes (a kind of semantic versioning). But again, that's another discussion :) Regards JB On Mon, Apr 8, 2024 at 5:20 AM Sutou Kouhei <k...@clear-code.com> wrote: > > Hi, > > I don't object this but I'm worry about we have enough > release managers for each component. Here are components: > > * C/GLib (me but I want to release C++ and C/GLib together > for .deb/.rpm packages) > * C++ (Raúl and me) > * C# (Curt?) > * Go (Matt?) > * Java (David?) > * JavaScript (Dominik?) > * MATLAB (Kevin?) > * Python (Alenka?) > * R (Jacob?) > * Ruby (me) > * Swift (me...?) > > Thanks, > -- > kou > > In <cahqx8+k9ntj7dqaxx8ac3fgdrfhe0rmnxs66byctm0-qsvy...@mail.gmail.com> > "[DISCUSS] Versioning and releases for apache/arrow components" on Thu, 28 > Mar 2024 21:42:14 +0100, > Jacob Wujciak <assignu...@apache.org> wrote: > > > Hello Everyone! > > > > I would like to resurface the discussion of separate > > versioning/releases/voting for monorepo components. We have previously > > touched on this topic mostly in the community meetings and spread across > > multiple, only tangential related threads. I think a focused discussion can > > be a bit more results oriented, especially now that we almost regularly > > deviate from the quarterly release cadence with minor releases. My hope is > > that discussing this and adapting our process can lower the amount of work > > required and ease the pressure on our release managers (Thank you Raúl and > > Kou!). > > > > I think the base of the topic is the separate versioning for components as > > otherwise separate releases only have limited value. From a technical > > perspective standalone implementations like Go or JS are the easiest to > > handle in that regard, they can just follow their ecosystem standards, > > which has been requested by users already (major releases in Go require > > manual editing across a code base as dependencies are usually pinned to a > > major version). > > > > For Arrow C++ bindings like Arrow R and PyArrow having distinct versions > > would require additional work to both enable the use of different versions > > and ensure version compatibility is monitored and potentially updated if > > needed. > > > > For Arrow R we have already implemented these changes for different reasons > > and have backwards compatibility with libarrow >= 13.0.0. From a user > > standpoint of PyArrow this is likely irrelevant as most users get binary > > wheels from pypi, if a user regularly builds PyArrow from source they are > > also capable of managing potentially different libarrow version > > requirements as this is already necessary to build the package just with an > > exact version match. > > > > A more meta question is about the messaging that different versioning > > schemes carry, as it might no longer be obvious on first glance which > > versions are compatible or have the newest features. Though I would argue > > that this a marginal concern at best as there is no guarantee of feature > > parity between different components with the same version. Breaking that > > implicit expectation with separate versions could be seen as clearer. If a > > component only receives dependency bumps or minor bug fixes, releasing this > > component with a patch version aligns much better with expectations than a > > major version bump. In addition there are already several differently > > versioned libraries in the apache/arrow-* ecosystem that are released > > outside of the monorepo release process. A proper support policy for each > > component would also be required but could just default to 'current major > > release' as it is now. > > > > From an ASF perspective there is no requirement to release the entire > > repository at once as the actual release artifact is the source tarball. As > > long as that is verified and voted on by the PMC it is an official release. > > > > This brings me to the release process and voting. I think it is pretty > > clear that completely decoupling all components and their release processes > > isn't feasible at the moment, mainly from a technical perspective > > (crossbow) and would likely also lead to vote fatigue. We have made efforts > > to ease the verification required for the vote easier and will continue > > these efforts. Though I can see some of the components managing their own > > releases (e.g. R, as we do with post release tasks already due to CRAN, ) a > > continued quarterly 'batch release' seems like a more appealing solution > > and would still allow us to use separate versions. Voting in one thread on > > all components/a subset of components per voter and the surrounding > > technicalities is something I would like to hear some opinions on. > > > > In my opinion being stricter with release requirements for components might > > lead to smaller/less active components not releasing. This seems like a > > bad thing at first glance but might also spur the user community to get > > involved when the reassuring, regular releases dry up and reflect the > > reality of the development situation of the component. > > > > I am eager to hear your thoughts! > > > > Best > > Jacob
