I am also in favor of this idea in general and in the principle, but (somewhat repeating others) I think we should be aware that this will create _more_ work overall for releasing (refactoring release scripts (at least initially), deciding which version to use for which component, etc), and not less, given that easing the burden of the release managers was mentioned as a goal. So we if pursue this, it should be for other benefits that we think this has: 1) because separate versions would be beneficial for users? (have a clearer messaging in the version number (eg no major new version if there were hardly any changes in a certain component, or use a versioning scheme more common in a certain language's ecosystem, ..?) 2) because it would actually allow separate releases, even though when initially always releasing in batch (eg being able to just do a bug fix for go, without having to also add a tag for all others) 3) because it would make the release process more manageable / easier to delegate? (and thus potentially easing the burden for an _individual_ release manager, although requiring more work overall) 4) .. other things I am missing?
> We could simply release C++, R, Python and C/GLib together. > ... > > I think that versioning will require additional thinking for libraries like > > PyArrow > I think we should maybe focus on a few more obvious cases. [i.e. not C++ and > Python] Yes, agreed to not focus on those. At least for PyArrow, speaking as one of its maintainers, I am personally (at this moment) not really interested in dealing with the complexity of allowing a decoupled Arrow C++ and PyArrow build. Related to the docs: > There is a dedicated documentation page for this... though the > versioning of the docs themselves would become ill-defined: > https://arrow.apache.org/docs/status.html ... > I think it would be best to hold off on Java also, in part because > of how the Java docs are integrated with the C++ and Python docs and > controlled by the version selector menu. We should indeed consider how to handle the current documentation site. Previously, we actually did some work to split the sphinx docs (used for the format, dev docs, and for the Python/C++/(part of the) Java docs) into multiple sphinx projects that could be built separately (https://github.com/apache/arrow/issues/30627, https://github.com/apache/arrow/pull/11980), but we abandoned that work last year because not seeming worthwhile. But we could certainly revive that idea, for example to at least split the format docs (and let that have its own versioning based on the Format Version (currently 1.4)? or just only host a single, latest version?) Joris
