Another possibility I'd like to float is doing this in ADBC first? My primary motivation is (1) from Joris's list: I'd like to bump a few components (Snowflake, maybe SQLite) to a "stable" version while leaving the others behind, and in this context I think it'd be much more helpful to users to differentiate between stable/experimental components. Admittedly this would not quite address the questions around versioning docs and so on.
On Tue, Apr 9, 2024, at 22:04, Antoine Pitrou wrote: > It seems that perhaps this discussion should be rebooted for each > individual component, one at a time? > > Let's start with something simple and obvious, with some frequent > contribution activity, such as perhaps Go? > > > > Le 09/04/2024 à 14:27, Joris Van den Bossche a écrit : >> 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
