The vote carries with 5 binding +1 votes and 1 non-binding +1. I will merge the change and open some JIRAs about the reference implementations adding forward compatibility checks that the bit width they receive is either null or 128
On Thu, Jun 25, 2020 at 4:02 PM Sutou Kouhei <k...@clear-code.com> wrote: > > +1 (binding) > > In <cajpuwmauhk4vdqd0lngvwgbmlj+edsmg9a3s6d4nnmcwsv2...@mail.gmail.com> > "[VOTE] Add Decimal::bitWidth field to Schema.fbs for forward > compatibility" on Tue, 23 Jun 2020 13:35:04 -0500, > Wes McKinney <wesmck...@gmail.com> wrote: > > > Hi, > > > > As discussed on the mailing list [1] I would like to add a "bit width" > > field to our Decimal metadata to allow for supporting different > > Decimal physical sizes other than 128-bit (where 32- and 64-bit > > representations are relatively common) without requiring that we add a > > new value to the Type enum on Schema.fbs, which would be rather > > unsightly. > > > > The PR with the new field is at [2]. We may make modifications to the > > language in comments but this vote is whether to accept the addition > > of this field. > > > > For clarity, this change is non-breaking and fully backwards > > compatible. The field ensures that current libraries will be able to > > determine if a future library version has sent data that uses a bit > > width other than 128. > > > > The vote will be open for at least 72 hours. > > > > [ ] +1 Accept addition of Decimal::bitWidth Flatbuffers field > > [ ] +0 > > [ ] -1 Do not accept addition because... > > > > [1]: > > https://lists.apache.org/thread.html/r97eecb373f5ea5f1c65a6f061c75af1ef7ac460f722f4c98a5c70dc2%40%3Cdev.arrow.apache.org%3E > > [2]: https://github.com/apache/arrow/pull/7321
