Re: Legacy support (Was: Base64 not there makes Rails 2.0.2 fail to load in 1.9.0)

On Dec 27, 2007 12:25 PM, Charles Oliver Nutter <[e-mail]> wrote:
> Richard Kilmer wrote:
> > I think it would be good to warn in 1.9 if the gem DOES NOT have the
> > required_ruby_version set (which most won't btw).  Warn that this gem
> > may not be compatible with Ruby 1.9.  It would also be helpful to have
> > this message at gem install time.  This is an annoyance, and like Dave
> > said, it will pressure people to update them, but at least we will then
> > know what gems are explicitly ready for 1.9.
>
> I raised this question on the RubyGems list and didn't get the answer I
> hoped...so I reraise it here:
>

I missed that message (or maybe the subject was different).

> How should one create a gem that works on both 1.8 and 1.9 given such
> major changes as String M17N?
>

If gem/lib developers aren't using low string processing (like mtaz
showed in his rubyconf presentation) I guess there will no be issues
with compatibilities.

> Or put another way...
>
> Shouldn't there be a way to release two copies of a gem, same version
> number, but targeting different major Ruby versions?
>

Mmm, another version number to keep track in the file schema for gems:

package_name-X.Y.Z.W-platform.gem
(X.Y.Z.W is version schema)

package_name-X.Y.Z.W-1.8-platfrom
(or 1.9)

Seems too confusing to get information about it.

I need to check the rubygems code and see if Installer is taking in
consideration < and >= for required_ruby_version, and not offering
gems when that requirement isn't meet.

> It seems like this is going to be more and more of a problem as gems are
> updated for Ruby 1.9. There are API changes that are going to be
> difficult to provide two paths for. And what about when 2.0 comes out
> some time in the future?

I guess there is no problem that both API coexist, like how the rails
guys did to fix the base64 deprecation (in repository, not officially
released yet).

Also, is up to the gem developers to have their own release and
compatibility policy.

As example, we (mongrel development team) discussed about 1.9 on
mongrel-development, so our position will be:

Mongrel 1.1 will be compatible with 1.8.x, and use
required_ruby_version '<1.9.0'

Mongrel is not a simple gem that could be "just patched" to be 1.9
compatible, and it requires a bit of work to make it take advantage of
the new 1.9 capabilities.

> Is it appropriate to ship both 1.8 and 1.9-compatible code inside every
> gem now? And then add 2.0 code later so it remains compatible with all
> three?
>

I don't know how many developers will start adapting all the lambdas
to the new ->, and I don't know what will be the API of Ruby for 2.0

> Given that 1.9 is still a development version, it seems like we could
> correct this and add platform or version-awareness to gems themselves,
> so if I install on 1.9 I could get the 1.9 version and on 1.8 get the
> 1.8 version of the same released gem.
>

Honestly was a real pain get platform (OS platform) awareness working
on Rubygems to now add _another_ variable to the equation.

Again I think this should be forwarded to the gem developers and they
should give their policies on what platform their gems/libraries
support.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams