Having a gem for 1.8 and 1.9

ruby-talk
1

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)

   2.

      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.

···

--
Posted via http://www.ruby-forum.com/.

2

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.

···

On Fri, Oct 2, 2009 at 1:00 PM, (RK) Sentinel <sentinel.2001@gmx.com> 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)

--
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

3

You may want to try out:

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

···

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)

4

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.

···

--
Posted via http://www.ruby-forum.com/\.

5

(RK) Sentinel wrote:

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 ?
  

Here's a small example:

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.

···

--
Florian Frank

6

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

http://rubyforge.org/projects/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

···

On Sat, Oct 3, 2009 at 12:12 AM, (RK) Sentinel <sentinel.2001@gmx.com> wrote:

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.

--
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