On Saturday 05 Feb 2005 21:49, Esteban Manchado VeláÛquez wrote:
> On Sat, Feb 05, 2005 at 10:29:11AM +0900, James Britt wrote:
> > Esteban Manchado VeláÛquez wrote:
> > >   And, w.r.t. the reply from James Britt, he said:
> > >>Sad, but unless you are paying someone you shouldn't expect
> > >>developers to be too concerned with writing new code that runs on
> > >>older versions of Ruby. (And I expect this is true in most developer
> > >>communities, so nothing scary about Ruby in this regard.)
> > >
> > >   Yes, you're right, you can't "expect" developers to do that, but I
> > > think Ruby would gain acceptance if more developers tried to remain
> > > compatible.
> >
> > That's, um, crazy.  Writing new code and checking that it runs in both
> > 1.6 and 1.8? Then you're basically writing to 1.6.
>
>    Yes, that is what I mean. Are there really so much performance-boosting
> features in Ruby 1.8 (the language; I guess the libraries should be easy to
> upgrade.... if they work in Ruby 1.6) that going to 1.6 for _some_
> important libraries sound crazy? It not telling everyone to not use new
> lenguage features (sorry if it sounded like that), I'm simply saying that
> keeping some important libraries/applications compatible with Ruby 1.6
> would probably make Ruby stronger in the eyes of many bussinesses.
>
It may be what you meant, but I don't think this is the important point. 

New code should NOT break old applications.  Period. 

I would like to leave that period there, but I accept that incompatible 
changes are necessary some times. They should be few and far between, well 
documented.

Curt's recent OnLamp article on rails was seriously weakened when, 5 days 
after it published, RAILS 0.9.5 was released and the examples refused to run. 

How many people, like me, have or will play with rails, only to find it did 
not work. Yet they were reading VERY recent stuff?  How many will conclude 
that Rails was not yet ready for serious consideration?   

(I am aware that rails is pre 1.0 - but it was broken by a mixture of changes, 
mostly in post 1.0 releases). 

If new code breaks old apps, people with production code, will not (can not, 
dare not) trust Ruby - they do not have the time to redevelop their app (in a 
hurry) every time someone uses gems and updates a library. 

The issue is not that I should write my code to work on 1.6 and 1.8.0 and 
1.8.1 and 1.8.2.  The issue is that my legacy app written in 1.6 should still 
run properly  when I update to later versions. 

Regards

Ian