Hi Matz, I’m glad to see that you’ve entered this fray.
I trust that you know me well enough to know, that while I have strong
opinions, I have no ill-will, particularly to you or your language.
On Fri, Feb 13, 2009 at 3:10 AM, Yukihiro M.
[email protected]wrote:
as I understand, they both contain bugs that haven’t disclosed for
1.8.6 by accident.
I consider them minor and not being worse than previous releases.
Most of them are addressed already. Am I missing something?
First, the next comment is directed to a subset of the Ruby community,
which doesn’t include you Matz,
I know that Rails isn’t liked by everyone in the Ruby community, but for
better or worse, it’s an important factor to the health of a significant
portion of ‘our’ community. Those who don’t use Rails or other large
Ruby
frameworks over time haven’t experienced how we got to the point where
these
problems have been addressed.
At this point, it’s a little hard to recover the history, but, although
Rails 2.2 is now compatible with Ruby 1.8.7 it has taken work, and new
releases, from both the Ruby team and the Rails team.
Rails users faced with upgrades, need to deal with the evolution of both
Ruby and Rails. To a large extent Rails over the last year to 18 months
has
been even more volatile than Ruby. Porting a Rails app from Rails 1.2.x
to
Rails 2.0 (There was no Rails 1.3) was, as the change in major version
number indicates a fairly significant jump. And Rails made changes in
Rails
2.2 which, for applications doing certain complex things with
ActiveRecord,
VERY difficult to port. That’s not Ruby’s fault, it’s just a fact of
life.
So there are quite a few Rails Apps, which need to stay on a version of
Rails which is compatible with Ruby 1.8.6, but won’t work with Ruby
1.8.7.
|Back then nobody stepped up and said that if code working on 1.8.6
|broke it is a bug so I just left it at that - the compatibility seemed
|to be not so great.
Of course, none of us is perfect, particularly without the benefit of
hindsight.
As a practitioner and advocate of agile techniques, I like to have a
comprehensive test suite to expose compatibility issues when changes are
made.
Unfortunately in the case of a language like Ruby, it’s impossible to
have
such a test suite, It would need to draw from a significant portion of
the
applications implemented in Ruby, and applications implemented on
frameworks
like Rails which are implemented on Ruby, etc. etc. Not really
practical.
If compatibility of 1.8.7 is really “not so great”:
-
if it is fixable, we can fix.
-
if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
as we did in the past.
-
if upgrading is not affordable for enterprisey people (yes, I
understand them; upgrading is costly even when incompatibility is
minor),
I’m not sure who you are calling enterprisey people here. I know that
you
have no intent to disparage, but that term does carry a certain meaning
of
“the other guys” with some of the Rubyists, (and others) I run into.
To me “enterprisey” means someone working in a large corporate
enterprise,
who is following strategies, architectures and standards, promulgated by
enterprise vendors, like Microsoft, and IBM (to the extent IBM still has
the
influence to do this), probably because of edicts handed down from on
high
from the executives who play golf with sales reps from those vendors.
I’m pretty sure that such “enterprisey” types make up a very small
subset of
the Ruby/Rails community. We don’t have many sales reps who play golf
with
corporate executives.
The vast majority of those using Rails are fairly small companies trying
to
leverage the almost unique advantages of Ruby and Rails to be able to
quickly deploy into production, and incrementally improve core business
applications. And the vast majority of Rails developers are either
working
for those small companies, or for a small Rails consultancy, or as
independent freelance contractors.
they can keep using 1.8.6, which is maintained right now.
Very true, I’ve got no argument with that, but it’s important to
understand
that those who are using packaged distributions of Ruby from debian
(including Ubuntu), RedHat, macports etc. have more trouble keeping
1.8.6
because normal system administration has a nasty tendency to replace
1.8.6
with 1.8.x where x > 6 because they don’t differentiate versions with
differences in teeny version numbers as backwards incompatible. While
1.8.7
is backwards compatible with 1.8.6 in theory. Whether or not it really
is,
depends on whether or not all of the ancillary ruby code on the
particular
system, like Rails, Gems, and local applications have been kept, or
brought
up to date.
Savvy developers get around this by eschewing packaged versions and
installing the components of the Rails stack, including Ruby, from
source.
But there are a lot of developers who trust the package maintainers, and
run
into these issues, and end up blaming Ruby. We could say “well that’s
their
problem,” if we don’t care about the impact on the overall perception of
Ruby. Perhaps that’s the right attitude, but I’m not so sure.
Would it have been better for those with these problems had Ruby 1.8.7
not
included the changes from 1.9 which broke apps and frameworks? I think
that
the answer is clearly yes.
But, for better or worse, it did, and we have to live with the
consequences,
that doesn’t mean we need to be happy about it.
As EngineYard raised their hands, the maintenance of 1.8.6 will be
kept, even after 1.8.8.
If more evidence of great incompatibility is not shown, I will
consider it FUD, or FUD-like at most, even though I see no bad
intention from anyone.
I hope that this doesn’t come across as FUD, or even FUD-like, I’m just
trying to put a bit more context on why compatibility isn’t a black or
white
thing, and the sources of real FUD.
The real FUD doesn’t come from discussions like this, it comes from
those
who either have run into these problems and blame Ruby. We have no
control
over what they say, we can only try to consider the effects of decisions
on
the broader community, within the bounds of our human lack of complete
knowledge.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
