Having a gem for 1.8 and 1.9

This is a simple query … I am back after a long hiatus so have
forgotten some basics of gem creation.

  1.  I am porting my gem from 1.8 to 1.9.
    

    I suppose if I just create a new version of the gem, it will not
    be clear to a user when installing which version he should install.
    Should I create 2 separate gems (2 separate names??) or use a 1.9
    suffix to my gem. (rbcurse and rbcurse19)

  At the same time, if a person is using 1.8 he should automatically

download the 1.8 version, and 1.9 users should get the 1.9 version
without having to specify or know that there are 2 versions of the gem.
Is this possible ?

Thanks.

On Fri, Oct 2, 2009 at 1:00 PM, (RK) Sentinel [email protected]
wrote:

This is a simple query … I am back after a long hiatus so have
forgotten some basics of gem creation.

  1.  I am porting my gem from 1.8 to 1.9.
    
    I suppose if I just create a new version of the gem, it will not
    be clear to a user when installing which version he should install.
    Should I create 2 separate gems (2 separate names??) or use a 1.9
    suffix to my gem. (rbcurse and rbcurse19)

If possible, I think it’s best to attempt to make 1 gem which works on
both. It’s easier for a pure Ruby gem than one with C extensions.

This means that you need to restrict the use of 1.9 feature inside the
gem, and have a good test suite which you can run against 1.8 and 1.9.

For my RiCal gem, I test against the latest 1.8.6, 1.8.7, and 1.9.

I’ve found a very few cases where I needed to write different code for
1.8 vs 1.9 because of the differences in Strings, but I’ve been able
to conditionally select which implementation of a few methods get
“compiled” by testing the ruby version inline.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Rick Denatale wrote:

1.8 vs 1.9 because of the differences in Strings, but I’ve been able
to conditionally select which implementation of a few methods get
“compiled” by testing the ruby version inline.


Rick DeNatale

Could you give me a snippet of your conditional selection ?

A link to your project code might help too. I’ve googled a bit, no files
released on http://rubyforge.org/frs/?group_id=8234 it seems.

Thanks.

On Oct 2, 2009, at 10:00 , (RK) Sentinel wrote:

This is a simple query … I am back after a long hiatus so have
forgotten some basics of gem creation.

  1.  I am porting my gem from 1.8 to 1.9.
    
    I suppose if I just create a new version of the gem, it will not
    be clear to a user when installing which version he should install.
    Should I create 2 separate gems (2 separate names??) or use a 1.9
    suffix to my gem. (rbcurse and rbcurse19)

You may want to try out:

http://tenderlovemaking.com/2009/05/07/fat-binary-gems-make-the-rockin-world-go-round/

(RK) Sentinel wrote:

Could you give me a snippet of your conditional selection ?

Here’s a small example:

http://github.com/flori/bullshit/blob/master/lib/bullshit.rb#L716

The code defines a log_gamma function: In 1.8 it uses its own Lanczos
approximation algorithm written in Ruby. In 1.9 Math already defines an
lgamma method with a complex result and a C-implementation which is used
instead if the lgamma method is defined there. If possible it’s better
to check for features you want to use from a specicific Ruby version
instead of checking for the version itself. This way you are prepared if
things change or features are eventually backported from Ruby 1.9.

On Sat, Oct 3, 2009 at 12:12 AM, (RK) Sentinel [email protected]
wrote:

A link to your project code might help too. I’ve googled a bit, no files
released on http://rubyforge.org/frs/?group_id=8234 it seems.

Au contraire mon frere. The code is on both rubyforge and github

http://rubyforge.org/projects/ri-cal/
http://github.com/rubyredrick/ri_cal

For some specific examples grep the project for “RUBY_VERSION” so far
there are only two files which are version sensitive

lib/ri_cal/component/calendar.rb
and
lib/ri_cal/core_extensions/date/conversions.rb

The first file works around the difference in Strings, and the second
has two methods which are included if ActiveSupport is also not
loaded, and we’re not running Ruby 1.9, for two methods which
ActiveSupport defines when running Ruby 1.8.x


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs