avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: Ruby gem fork - contribute back?
Date Wed, 25 Jun 2014 09:33:46 GMT
IIRC, the multijson issue is fixed in the current snapshot.

I dunno, I certainly stopped using Ruby 1.8 several years ago. The issue is
that Avro has a strong history of favoring compatibility. It would be
surprising for us to drop Ruby 1.8 support while still in the Avro 1.7 line.

We could plan to only support Ruby 1.9+ in Avro 1.8 and take a contribution
that targeted that, maybe?

-- 
Sean
On Jun 25, 2014 4:16 AM, "Willem van Bergen" <willem@vanbergen.org> wrote:

> I forked off trunk 2 days ago.
>
> It's possible to have 2 different gems, but this is not very common in the
> Ruby world. Because Ruby 1.8 is not maintained anymore, not even for
> security issues, most people have moved on to newer versions. This is in
> contrast with Python 2, which is still maintained and heavily used.
>
> My preference would be to document that the last release of avro that
> supports Ruby 1.8 is 1.7.5. (Version 1.7.6 won't install because of the
> multi_json issue). Maintaining 1.8 compatibility will be harder and harder
> over time and hold back development. E.g. it is already hard to even
> install a Ruby 1.8 version on a recent OSX due to compiler changes.
>
>
> Cheers,
> Willem
>
>
> On Jun 25, 2014, at 5:06 AM, Sean Busbey <busbey@cloudera.com> wrote:
>
> > how far back did you fork?
> >
> > could we have a Ruby 1.8 gem and a Ruby 1.9+ gem?
> >
> > we have python and python 3 support broken out, for example.
> >
> >
> > On Wed, Jun 25, 2014 at 3:51 AM, Willem van Bergen <willem@vanbergen.org
> >
> > wrote:
> >
> >> Hi,
> >>
> >> For a Ruby project, I am using AVRO schemas to validate Ruby objects.
> >> Because I ran into some issues with the official avro gem, so I forked
> it:
> >> https://github.com/wvanbergen/tros. (The name probably only makes sense
> >> to Dutch people :)
> >>
> >>
> >> ### Changes
> >>
> >> - Fixed a round trip encoding issue for union(double, int) types.
> >> Integers were being encoded as floats, and read back as float. In Ruby
> >> versions 2.0 and later, a float == bigint equality check will return
> false.
> >> This caused a test to fail.
> >>
> >> - Fix UTF-8 support for Ruby 1.9+, and JRuby.
> >> The original code was written for Ruby 1.8, and there's some big changes
> >> to how to properly do this in Ruby 1.9+ and JRuby.
> >>
> >> - Remove monkey patching of Enumerable
> >> Monkey patching builtin objects is frowned upon, especially in
> libraries.
> >> Fixing it was easy:
> >>
> >>
> https://github.com/wvanbergen/tros/commit/c81d6189277111008ebb05239af91d286dd01061
> >>
> >> - Dropped dependency of yajl-ruby and/or multi_json.
> >> The yajl-ruby dependency was causing compatibility issues with the rest
> of
> >> my application, and there's no released version yet with working
> multi_json
> >> (1.7.6 cannot be installed because multi_json is misspelled multi-json).
> >> Instead of fixing that, I decided to simply use Ruby's built in support
> for
> >> JSON. For libraries, the less external dependencies the better.
> >>
> >>
> >> I also did some heavy refactoring to make the Ruby codebase work outside
> >> of the context of the greater Avro project, and applied some best
> practices
> >> of the Ruby ecosystem. Finally, I set up CI (
> >> https://travis-ci.org/wvanbergen/tros) that checks the gem on multiple
> >> Ruby versions.
> >>
> >>
> >> ### Contributing back?
> >>
> >> I would like to contribute back my changes if you are interested.
> However,
> >> maintaining Ruby 1.8 support will make this very hard. Ruby 1.8 doesn't
> >> come with built in JSON support, and it's unicode handling is severely
> >> broken. It is also no longer maintained:
> >>
> https://www.ruby-lang.org/en/news/2013/12/17/maintenance-of-1-8-7-and-1-9-2/
> >>
> >> Is it acceptable to drop support for Ruby 1.8? If so, I can work with
> you
> >> to get my changes back into the main codebase.
> >>
> >>
> >> Cheers,
> >> Willem van Bergen
> >
> >
> >
> >
> > --
> > Sean
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message