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
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 o
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 les
Hi David,
Yeah, maybe my "wording" is not accurate, sorry about that.
Core is not correct. Maybe common or another wording is more appropriate.
Basically, the idea is to first release a component that it's used by
other components. And the release cycle can be "atomic"/decoupled
between component
I think it is worthwhile to pursue this, but I fear that if we do not
proceed very carefully, unforeseen complications could arise, creating even
greater work for the release managers.
> In general I think that this is not something we neither need to nor want
to implement from 0 to 100.
> Increme
Java has JNI parts, but I think they do not necessarily need to release at the
same time as C++, especially since the JAR bundles the libraries; Java could
just pick up the latest version of the C++ library whenever it releases. It
would make it harder if the next step is to also decouple the re
Hi,
Yeah, to be honest, I was more focused on Java versioning.
Maybe, we can "group" Arrow components in two major areas: the "core"
libs and the components using the "core" libs.
C++ can have its own versioning, and the rest is decoupled from each
other but it will depend to C++ release.
I thin
Thanks for the eager discussion, great to see that we are aligned on the
broad strokes!
In general I think that this is not something we neither need to nor want
to implement from 0 to 100.
Incrementally evolving and evaluating our process is key for sucsh a core
change
> I think C#, JS, [Java], a
> Probably major versions should match between C++ and PyArrow, but I guess
> we could have diverging minor and patch versions. Or at least patch
> versions given that
> a new minor version is usually cut for bug fixes too.
I believe even this would be difficult. Stable ABIs are very finicky in
C
On Sun, Apr 7, 2024 at 3:06 PM Andrew Lamb wrote:
>
> We have had separate releases / votes for Arrow Rust (and Arrow DataFusion)
> and it has served us quite well. The version schemes have diverged
> substantially from the monorepo (we are on version 51.0.0 in arrow-rs, for
> example) and it doe
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
> "[DISCUSS] V
)
* MATLAB (Kevin?)
* Python (Alenka?)
* R (Jacob?)
* Ruby (me)
* Swift (me...?)
Thanks,
--
kou
In
"[DISCUSS] Versioning and releases for apache/arrow components" on Thu, 28
Mar 2024 21:42:14 +0100,
Jacob Wujciak wrote:
> Hello Everyone!
>
> I would like to resurfa
Le 28/03/2024 à 21:42, Jacob Wujciak a écrit :
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.
We could simply
I agree with all the other comments on this thread
Having smaller releases is key to being able to release more frequently and
finding the relevant expertise in my opinion.
We have had separate releases / votes for Arrow Rust (and Arrow DataFusion)
and it has served us quite well. The version sch
Thank you Jacob for bringing this up! I am also in favor of decoupling
versions (provided that the release managers are also in favor of
this, since their time is required to implement this and because the
ongoing consequences of separate releases disproportionately affects
them).
Part of the vote
Thank you for bringing this up. I'm in favor of this. I think there are
several motivations but the main ones are:
1. Decoupling the versions will allow components to have no release, or
only a minor release, when there are no breaking changes
2. We do have some vote fatigue I think and we don
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
17 matches
Mail list logo
