Thanks for bringing this up. My thought is: - We are treating ADBC's APIs as a specification, so we should vote in general. - The changes here are minimal and don't introduce any compatibility concerns - they just add more constant definitions - so I say we vote and just merge them into main, instead of adding more friction.
There is a set of more major proposals I have begun collecting here [1] that would require some work to maintain compatibility. For those, I think we would want to do development on a branch, then vote and merge them and bump the specification version. And ideally, bundle these changes and any others together to avoid introducing a lot of work for implementations to maintain compatibility. -David On Wed, Jan 11, 2023, at 11:44, Matt Topol wrote: > Hey all, > > I've filed a PR with ADBC (https://github.com/apache/arrow-adbc/pull/316) > to add some more explicitly defined canonical options. This then leads the > an interesting question that should be posed: > > For changes like this in general along with other potential updates, should > we do a series of small votes that are merged into a branch and then > bundled up into a v1.1.0 release? Or just do votes to merge to main and > then bump to v1.0.1? Or some other combination of ideas? As this is > technically a change to the ADBC definitions, it should warrant some kind > of release, but it might end up spammy to bump versions frequently for > changes like this for now? > > Anyway, I figured it'd be good to open it up for discussion here and see > what people's opinions on this are. > > Thanks all! > > --Matt
