On Thu, 20 Oct 2022 at 17:05, sebb <seb...@gmail.com> wrote: > > On Thu, 20 Oct 2022 at 15:43, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > Would't it be simpler to deal with the serialization issue by bumping the > > serialVersionID? We can just say that you only serialized and deserialize > > for the same version. > > Are we willing to continue supporting serialisation going forward? > It is not easy to ensure compatibility and avoid security issues. > > Are there any use-cases for allowing serialisation?
Serialisation was broken for CSVRecord before and partially fixed in 1.8 to support 1.0 to 1.6. Fields from 1.7 are not supported. The release notes for 1.8 state that serialisation will not be supported going forward. So this breakage of serialisation for CSVFormat has precedent. I think Gary's suggestion to change the serial version ID commits to the same path as not supporting serialisation from 2.0. Regarding the release, I am not concerned about serialisation as it seems to be a lost cause. The issue is the behavioural compatibility of switching from a boolean flag for duplicate headers to an enum with 3 options. We should get this correct to avoid a future release having to explain a behavioural compatibility change. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
