Hi Alex, Is there more you'd like to do for 1.8?
Gary On Fri, Jan 24, 2020 at 12:36 PM Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Jan 24, 2020 at 11:09 AM sebb <seb...@gmail.com> wrote: > >> On Fri, 24 Jan 2020 at 15:05, Alex Herbert <alex.d.herb...@gmail.com> >> wrote: >> > >> > >> > On 24/01/2020 13:34, Gary Gregory wrote: >> > > On Fri, Jan 24, 2020 at 6:14 AM sebb <seb...@gmail.com> wrote: >> > > >> > >> On Thu, 23 Jan 2020 at 18:10, Alex Herbert <alex.d.herb...@gmail.com >> > >> > >> wrote: >> > >>> >> > >>> On 23/01/2020 13:55, sebb wrote: >> > >>>> I think we don't want temporary serialisation fixes to encourage >> the >> > >>>> use of serialisation. >> > >>>> >> > >>>> So I suggest that the Release Notes and Javadoc should point out >> that >> > >>>> although serialisation is possible, it is not fully supported, and >> > >>>> that there are plans to drop all serialisation support. >> > >>> The javadoc for the new field that is not serialized have been >> > >>> documented. This current code is able to deserialize a record >> created >> > >>> using version 1.0 and 1.6. I did not test the in between releases. >> > >>> Serialisation broke in 1.7. >> > >>> >> > >>> Should a note be added to the header for CSVRecord stating that the >> > >>> class is serialization compatible with version 1.0 - 1.6. Fields >> added >> > >>> after version 1.6 are not serialized and the intension is to remove >> > >>> serialisation support in version 2.0. >> > >>> >> > >>> WDYT? >> > >> LGTM (apart from some spelling issues!) >> > >> >> > >> However, I think it's worth noting in the Release Notes as well. >> > >> >> > > I'm OK with what Sebb said. >> > > >> > > Gary >> > >> > OK. I'll update the description in the changes.xml for this release >> > (which IIUC become the release notes) >> >> This is not automatic, but yes, changes.xml can be used to generate the RN >> > > I use the changes.xml file to generate the RNs. > > Gary > > >> >> > and javadoc the CSVRecord in the >> > class header. >> >> Thanks! >> >> > Alex >> > >> > > >> > > >> > >>> Alex >> > >>> >> > >>> >> > >>> >> > >>> >> --------------------------------------------------------------------- >> > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >>> For additional commands, e-mail: dev-h...@commons.apache.org >> > >>> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> > >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
