There isn't a branch for 1.8. Patches that target that version just get generated based on trunk and attached to tickets with a fix version of 1.8.0. Generally, they also get hte incompatible flag.
Sure, I agree that using the unreleased versions isn't tenable. Doug made a call for a 1.7.7 release back at the end of may[1]. It would be good to ping that thread with the important of getting something soon for the Ruby folks. [1]: http://s.apache.org/1LB On Wed, Jun 25, 2014 at 4:54 AM, Willem van Bergen <[email protected]> wrote: > Dropping support for Ruby 1.8 in the Avro 1.8.x series sounds like a plan. > Is there already a branch for the 1.8 series? > Until that time happens, I can maintain my fork for people requiring > unicode UTF support on Ruby 1.9+. > > I know the multi_json issue is fixed in trunk. However, due to the > project's structure, it's very hard to use a non-release version inside a > project. > Because the project doesn't include a gemspec file, you cannot make > Bundler use the latest trunk version. > (In my case, I use avro inside of another gem. Gem can only depend on > released versions of other gems, so I had to fork & release it.) > > > Willem > > On Jun 25, 2014, at 5:33 AM, Sean Busbey <[email protected]> wrote: > > > 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" <[email protected]> > 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 <[email protected]> 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 < > [email protected] > >>> > >>> 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 > >> > >> > > -- Sean
