Hi,

On 2019/03/29 21:26:02, "Driesprong, Fokko" <fo...@driesprong.frl> wrote: 
> Thanks all for the feedback.
> 
> Regarding the discussion Joda time, I've made a PR to completely remove the
> Joda dependency: https://github.com/apache/avro/pull/495
> 
> What do you guys think, could we push this for 1.9? This would obviously
> break backward compatibility, but then again, people should not use Joda
> time anymore.

New projects should not use Joda, but some old projects still use/support it. 

I'd suggest to keep Joda conversions in 1.9 (as Deprecated, maybe) and drop 
them in 1.10.
This way you would give people chance to upgrade and migrate in their own pace. 
Doing a big upgrade+migrate usually is a pain and people just stay with the old 
version.

Looking forward for 1.9 to being released!
Thank you!

Regards,
Martin

> 
> Cheers, Fokko
> 
> Op vr 29 mrt. 2019 om 10:37 schreef Nandor Kollar
> <nkol...@cloudera.com.invalid>:
> 
> > I totally support making JSR310 as the default instead of Joda
> > time. Should we consider removing the JSR310 from the class names, for
> > example rename Jsr310TimeConversions to TimeConversions and the existing
> > TimeConversions to JodaTimeConversions, and deprecate the latter?
> >
> > On Thu, Mar 28, 2019 at 6:53 PM Daniel Kulp <dk...@apache.org> wrote:
> >
> > > I made few commits today that change the generated code from the Schema
> > > compiler a bit….  The changes make Avro 1.9 a bit more incompatible with
> > > 1.8, but since they are going to have to migrate anyway, I thought it
> > would
> > > be important to make the changes now rather then forcing everyone to do
> > so
> > > in 1.10.   The changes:
> > >
> > > 1) Default for “time” classes change from Joda to JSR310.  There is a
> > flag
> > > to specify joda if they need/want it, but I think the “default” should be
> > > what we plan on supporting going forward, and I don’t think joda should
> > be
> > > it.     At this point, joda should go away.  :)
> > >
> > > 2) Private fields  - we were, by default, generating “@Deprecated public”
> > > fields.   The idea of generating deprecated code by default annoys me.
> > >  Thus, I changed the default to “private”.  Again, there is a setting to
> > > make them public (or deprecated/public) if they want it, but for the
> > > default, I believe private is what we want.
> > >
> > > While those will increase the effort to migrate from 1.8 to 1.9, I think
> > > it’s better to do that now than waiting any longer.
> > >
> > > Thoughts?
> > > Dan
> > >
> > >
> > > > On Mar 26, 2019, at 9:31 AM, Driesprong, Fokko <fo...@driesprong.frl>
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I'd like to cut the branch for Apache Avro 1.9 release this Friday, and
> > > > start moving to a release candidate so we can test. If there are any
> > > > features that you would like to get in, please let me know.
> > > >
> > > > Cheers, Fokko
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <
> > > http://dankulp.com/blog>
> > > Talend Community Coder - http://talend.com <http://coders.talend.com/>
> > >
> >
> 

Reply via email to