Personally, I'd rather see #2. I think it's very hard to know what the current use of Ruby 1.8 is. Support from the MRI community only ended ~1 year ago[1]. JRuby still supports running in 1.8 mode. They'll be dropping it in their next major release, but there isn't a schedule for that yet and they expect the current major release line to continue for some time after that[2]. Additionally, Heroku won't be ending support until the end of this month[3]. Even after that, it's not clear to me that they won't allow users to keep using it.
As mentioned previously I'm a JRuby-in-1.9-mode user and I usually just work with the Java libraries directly. So this won't directly impact me, but I agree that it sucks when upgrades break things. So I don't feel like #1 is an option. We could also investigate maintaining a single gem that just had two implementations with in it, with the active one determined by the Ruby version. [1]: https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/ [2]: https://groups.google.com/d/msg/jruby-users/qmLpZ7qDwZo/J_iYViplcq4J [3]: https://devcenter.heroku.com/articles/ruby-support#ruby-versions -Sean On Wed, Jun 25, 2014 at 6:41 PM, Doug Cutting <cutt...@apache.org> wrote: > On Wed, Jun 25, 2014 at 2:16 AM, Willem van Bergen <wil...@vanbergen.org> > wrote: > > 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. > > I can see a couple of options: > 1. Assume that no one actually uses Ruby 1.8 anymore, and upgrade to > 1.9 in Avro 1.7.7. A change that doesn't break anyone isn't > incompatible. > 2. Assume some folks still use Ruby 1.8 and add a ruby1.9 fork in > Avro 1.7.7. Ruby users who upgrade to Avro 1.7.7 would need to opt-in > to the Ruby 1.9 version. > 3. Wait until we release 1.8.0 to upgrade Avro to support Ruby 1.9. > > (3) seems like a bad option unless we're confident we're going to > release a 1.8.0 soon, which I am not. Folks hate getting broken by > upgrades. Avro is a dependency of a lot of Java applications. Having > an incompatible release makes it hard for one component to upgrade > without forcing all to upgrade. Either you end up with a broken stack > or with one that can never upgrade. Which of (1) or (2) seems more > palatable to Ruby folks? Are there other options? > > Doug > -- Sean
