I think it would be reasonable to state that a reference implementation must be a complete implementation (i.e. supports all existing types) that is not derived from another implementation (e.g. you can't pick pyarrow and arrow-c++). If an implementation does not plan on ever supporting a new array type then maintainers of that implementation should be empowered to vote against it. Given that, it seems like a reasonable burden to ask maintainers to catch up first before expanding in new directions.
On Fri, Jan 6, 2023 at 10:20 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > > > > > Note this wording talks about "two reference implementations" not "*the* > > two reference implementations". So there can be more than two reference > > implementations. > > > Maybe reference implementation is the wrong wording here. My main concern > is that we try to maintain two "feature complete" implementations at all > times. I worry if there is a pick 2 from N reference implementations that > potentially leads to fragmentation more quickly. But maybe this is > premature? > > Cheers, > Micah > > > On Fri, Jan 6, 2023 at 10:02 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > Le 06/01/2023 à 18:58, Micah Kornfield a écrit : > > > I'm having trouble finding it, but I think we've previously agreed that > > new > > > features needed implementations in 2 reference implementations before > > > approval (I had thought the community agreed on Java and C++ as the two > > > implementations but I can't find the vote thread on it). > > > > Note this wording talks about "two reference implementations" not "*the* > > two reference implementations". So there can be more than two reference > > implementations. > > > > Regards > > > > Antoine. > >
