If you are unhappy with the direction of Ruby 1.8.7+, respond

[Eleanor McHugh]

Don't just say it, show it.

http://vividpicture.com/aleks/atari/forth.jpg

Too many old Forth hands on here ;p

With all this back-porting it's as if the foreshadowed magnitude of
Ruby 2.0 is making the core team nervous of turning 1.9 into a genuine
stable branch, so instead they're forcing the stable features into 1.8
instead. I'm sure this is a complete misreading of their intent on my
part but it is a worrying path to be heading down.

I'll admit that so far I've not had any problems with 1.8.7 but my
colleague Romek has been having a horrible time with its OpenSSL
support and quite a few of the tools he's written with 1.8.6 no longer
work. We're currently debating whether or not to bite the bullet and
move to 1.9.1 - assuming the current crop of books are an accurate
representation.

Anyway if I or another developer want 1.9 features and/or syntax we'll
use 1.9 and the fact that some of us choose not to do so at this time
is something I'd like to see respected by the core team.

+1


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Charles Oliver Nutter]

I am not happy.

Ruby 1.8.7 and Ruby 1.8.8 are attempts to bridge the gap between 1.8.6
and 1.9, but they change the 1.8 line in much more drastic ways that is
warranted by a minor version number change. That's one point against them.

A similar approach in the Python community has led to 2.6, 2.7 releases
stepping toward 3.0, but those are major release version number changes
and they're only doing them if the community demands them. In this case,
1.8.7 and 1.8.8 are moving forward whether the community wants them or
not. Another point against.

Minor version releases should certainly not break things except as
needed to fix bugs. Ruby 1.8.7 did this initially. They should not add
entirely new APIs incompatible with other minor releases. They should
not add new syntax incompatible with other minor releases. Ruby 1.8.7
does the former, and 1.8.8 syntax backports will do the latter. More
points against.

I still feel like Ruby 1.9 should have been 2.0. Then 1.8.7 could have
been 1.9, 1.8.8 could be 1.10, and so on, and people depending on "Ruby
1.8" to behave like "Ruby 1.8" would not be forced to upgrade.

In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine
standalone releases, but making them be minor version number changes
essentially forces everyone to upgrade eventually, whether they want to
or not, since Ruby distributors generally don't expect a 0.0.x release
to be filled with incompatible changes or additions. Ubuntu, for
example, now installs 1.8.7 by default, so Ubuntu users are now much
more likely to write code that doesn't work on 1.8.6.

And note also that Ruby core has only a few resources to maintain Ruby
versions...which means the existence of 1.8.7 and plans for 1.8.8 will
eventually force 1.8.6 to be abandoned like 1.8.5 and 1.8.4. How would
you feel about 1.8.6 being EOLed because of 1.8.7 and 1.8.8 taking up
resources?

- Charlie

 

[Robert Dober]

I am setting up two threads in the hopes that we can see names
attached to opinions about the decision to break backwards
compatibility between Ruby 1.8.6 and Ruby 1.8.7+
This one is for those who wish that Ruby 1.8 would go *back* to being
1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your
thoughts or at least a simple '+1'. If you disagree, please find the
other thread titled 'If you are happy with the direction of Ruby
1.8.7, respond'. If you are in the middle, I don't know what you
should do... write two posts?

My goal is to survey ruby-talk so that the core Ruby team has a chance
to see what people really want. I'm curious to see if this is as
one-sided as I think it is.

-greg

Good idea Greg, now that Ruby1.9 is out I really fail to see the
advantages of this.
I am writing lots of compatibility code between 1.8.6 1.8.7 and 1.9
and that really is time not too well spent.

I would like 1.8.6-->1.8.8 so that I can just drop 1.8.7 support

1.8.7, 1.8.9 not really a strong opinion here, those could follow the
rule of dev. releases: use on own risk.
1.9 of course is great no complaints.

Cheers
Robert

 

[w_a_x_man]

The process of ANS standardization focused the Forth community and
produced a syntax and semantics that are well-regarded in today's Forth
community. I wouldn't be using Forth today if it weren't for the ANS
standard!

The process of ANS standardization decimated the Forth community and
produced a syntax and semantics that are grudgingly accepted by some
in today's tiny Forth community.

He wouldn't be using Forth today if it weren't for the ANS
standard! (A strong argument against standardization.)

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

I am setting up two threads in the hopes that we can see names
attached to opinions about the decision to break backwards
compatibility between Ruby 1.8.6 and Ruby 1.8.7+
This one is for those who wish that Ruby 1.8 would go *back* to being
1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your
thoughts or at least a simple '+1'. If you disagree, please find the
other thread titled 'If you are happy with the direction of Ruby
1.8.7, respond'. If you are in the middle, I don't know what you
should do... write two posts?

My goal is to survey ruby-talk so that the core Ruby team has a chance
to see what people really want. I'm curious to see if this is as
one-sided as I think it is.

+1024!

Others have pointed out the folly of having a teeny version number change
carry API breaking changes.

Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

On an aside do any of the OS X users know if there's a way in Macports to
pin the version number of a package? The whole Ruby 1.8.7 thing has made me
very paranoid of doing an errant port upgrade.

 

[Robert Klemme]

I'm bothered by the new versioning scheme.

The new releases involve big changes and even if they are fully
backwards compatible about what they will run, they are still creating
pretty big compatibility gaps. Code using any of the new 1.8.7
features won't run on 1.8.6 and lower.

Well, but this is usual, isn't it? If you want exact 1.8.6 then take
1.8.6. Or do you see changes in the third number as sole bug fix changes?

It sounds as if 1.8.8 intends
to take this farther, so code written to that won't work in the
different 1.8.7 branch or the earlier 1.8.6 and lower stuff.

But if I understand this correctly, 1.8.6 code will also run on 1.8.7
and later.

Thus I
feel we now have three different versions of Ruby 1.8 on the table
(counting the not yet released 1.8.8).

That seems to be the case. Maybe 1.8.7 should really have been 1.9.0
but that version is taken already... IMHO the changes in 1.9 are big
enough to warrant a 2.x but I guess Matz et al. have put quite a bit of
thought into the version numbers - so maybe we should hear that before
we make any judgments about what fits in a release and what not.

Kind regards

robert

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

Matz and his team announced that they were beginning and effort towards this
end at RubyConf 2008.

However, I'm not sure I understand if their approach of doing this under the
aegis of (IIRC) the Linux Foundation gets us to an ISO standard, based on my
experiences of the ANSI/ISO process when I worked on standards like X3J20
for Smalltalk.

2. There are two "de facto" standards for the Ruby language at present.
a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
"Programming Ruby 1.9" and "The Ruby Programming Language".

All other versions are irrelevant and a waste of precious developer
energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two "de
facto" standard versions have designated numbers already, why not keep
them as they are?

As others point out, there are a lot of packaging systems which make the
assumption that a minor version number change is compatible. When the ruby
team breaks that assumption, it can cause havoc for those who install and
maintain their system with standard tools like dpkg/apt-get, ports, etc.

Some of the maintainers of packaged software don't really work with the
packages they maintain, and aren't necessarily aware of or appreciative of
philosophical differences like these. When the upstream developers break the
assumptions of the package maintainers, it can lead to as much trouble as
when the package maintainers disagree with the philosophy of the upstream
developers and do things their own way. I'm talking about what debian/ubuntu
do/did to rubygems here.

 

[Pit Capitain]

Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

I've seen many people claiming this, and they might be right of
course, but no one has shown any examples yet. If it is so hard to
find 1.8.6 code that doesn't work with 1.8.7, the backward
compatibility of 1.8.7 seems to be pretty good.

Regards,
Pit

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

Well, but this is usual, isn't it? If you want exact 1.8.6 then take
1.8.6. Or do you see changes in the third number as sole bug fix changes?

That's the industry practice, a minor version number change normally means
that there should be no or very little impact on the installed base of
'legacy' code.




It sounds as if 1.8.8 intends to take this farther, so code written to

that won't work in the different 1.8.7 branch or the earlier 1.8.6 and
lower stuff.

But if I understand this correctly, 1.8.6 code will also run on 1.8.7 and

later.

I must say that I'm not entirely up to date with what NOW works on 1.8.7,
the stuff which used to break, e.g. rails and many gems has been catching up
to the changes, but that is cold comfort for those who are faced with a
broken deployment and either have to back-level dependencies, or go through
a sometimes painful process of migrating a large application from the
version of, say rails, they were using to the new one which runs on 1.8.7.

It's not so much of a problem for folks writing standalone code, or code
with a small set of dependencies, but it has, and I suspect it continues to
have, a large impact on a lot of folks trying to maintain their bread and
butter.

Thus I feel we now have three different versions of Ruby 1.8 on the

That seems to be the case. Maybe 1.8.7 should really have been 1.9.0 but
that version is taken already... IMHO the changes in 1.9 are big enough to
warrant a 2.x but I guess Matz et al. have put quite a bit of thought into
the version numbers - so maybe we should hear that before we make any
judgments about what fits in a release and what not.

As I remember it, Matz didn't want to have a version number like 1.8.10, and
since there was danger of 'running out' the version numbering scheme was
changed to make 1.9.0 the 'unstable' development release, and use a teeny
number greater than or equal to 1 to indicate stability. This was OK as it
stood, but then 1.8.7 came along and introduced incompatible changes
backported from 1.9.0.

Regardless of the percentage of gems and frameworks which have been updated
to work with 1.8.7. I still maintain that the backporting in 1.8.7 was a bad
idea, and pushing it further would compound the problem.

 

[James Gray]

I've seen many people claiming this, and they might be right of
course, but no one has shown any examples yet.

This is trivial to prove. This code:

Object.new.tap { |o| p o }

runs on 1.8.7 and not 1.8.6.

James Edward Gray II

 

[Alex Fenton]

I've seen many people claiming this, and they might be right of
course, but no one has shown any examples yet. If it is so hard to
find 1.8.6 code that doesn't work with 1.8.7, the backward
compatibility of 1.8.7 seems to be pretty good.

Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

But this misses the main point - that there is no assurance that code
developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of
checking, other than scrutinising the ChangeLog. This is a huge
disservice to library authors and users.

a

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

This is trivial to prove. This code:

Object.new.tap { |o| p o }

runs on 1.8.7 and not 1.8.6.

True, although the real issue is that there is code which runs on 1.8.6 and
doesn't run 'correctly' on 1.8.7.

The real problem is when the semantics have changed, and this breaks
frameworks and gems and such.

 

[F. Senault]

Le 11 février 2009 à 22:53, Alex Fenton a écrit :

Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

But this misses the main point - that there is no assurance that code
developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of
checking, other than scrutinising the ChangeLog. This is a huge
disservice to library authors and users.

Somehow, I was wondering why the "new" code in 1.8.(7|8) isn't made
available through a library.

Something like :

require "compat-1.9"

Object.new.tap { |o| p o }

I guess that it's a lot of work if it's implemented in C, but maybe the
work that went into backporting the functionality was misdirected and
could have been more useful in doing a few ruby-written libraries to
help smoothen the transition...

My 2 euro-cents.

Fred

 

[Pit Capitain]

Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

AFAIK 1.8.7 introduced a method that Rails was using. This could have
happened in previous Ruby upgrades as well. I don't see why this is
something special with 1.8.7.

As for the C extensions: do you have more information about what was
changed in the Ruby internals that lead to those problems?

But this misses the main point - that there is no assurance that code
developed using 1.8.7 (or 1.8.8) will run on 1.8.6.

Again, this is nothing special with the 1.8.7 release. It has been
like this since I'm using Ruby, which is since 2000. The important
point is that (most) 1.8.6 code still runs on 1.8.7.

The only thing I understand you having problems with is that for other
software projects you can expect that for example no new methods are
introduced between a.b.c and a.b.d, so that the Rails problem wouldn't
have occurred there. But, again, Ruby version numbers have never been
working like that. Despite this we have been able to arrive at 1.8.6,
and I still don't see what's so special with 1.8.7 that we should stop
at 1.8.6.

Regards,
Pit

 

[Serabe]

True, although the real issue is that there is code which runs on 1.8.6 and
doesn't run 'correctly' on 1.8.7.

The real problem is when the semantics have changed, and this breaks
frameworks and gems and such.

But this is because the former was consider a bug or for another
reason? For example, (taken from
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/NEWS )

* Date.parse

'##.##.##' (where each '#' is a digit) is now taken as 'YY.MM.DD'
instead of 'MM.DD.YY'. While the change may confuse you, you can
always use Date.strptime() when you know what you are dealing
with.

Looks like a really strange change to me. In fact, it confuses me. Ok,
I know I can use Date.strptime when I know what I'm dealing with, but
I still don't get the point.

Someone can enlighten me, please?

Regards,

Serabe

 

[Urabe Shyouhei]

All other versions are irrelevant and a waste of precious developer
energy as far as I'm concerned.

But what if they want to waste their energy there?

To maintain an old piece of crap like MRI cannot be nothing but boring. Every
precious developers you can think of is precious just because he/she can create
a bright new idea. No one wants to nurse a dead-ended product.

 

[Trans]

+1 if 1.8.7 can't run 1.8.6 code. I don't so much care if they *add*
abilities to bridge to 1.9.

That said, I have a simple solution. Move to 1.9.1 as fast as your
fingers will allow. Do not pass go. Do not collect $200. Get'r done.

T.

 

[James Coglan]

[Note: parts of this message were removed to make it a legal post.]

I've seen many people claiming this, and they might be right of
course, but no one has shown any examples yet. If it is so hard to
find 1.8.6 code that doesn't work with 1.8.7, the backward
compatibility of 1.8.7 seems to be pretty good.

Requires hoe, ZenTest and 1.8.6 and 1.8.7 installed using multiruby:

git clone git://github.com/jcoglan/packr.git packr
cd packr
git co -b 3.1 origin/3.1
git co 4cc307
rake multi

This is not using any new 1.8.7 features, it's using 1.8.6 behaviour that
broke. Under 1.8.6, hashes had keys inserted in the order in which they
appear in the source, which is not true of 1.8.7. Granted, this ordering was
never explicitly intended for 1.8.x, but still it introduced major bugs in
my code. PackR still has a bug I'm unable to fix on 1.8.7, though thankfully
it's not a show-stopper, it's a nice-to-have 'bonus feature' that doesn't
work.

I for one do not want to pull updates to ruby1.8 from my package manager and
have even more of my code break, esp. as I maintain various libraries and
it's hell having to explain to people that my code is broken because their
package manager is not fine-grained enough and they need to install stuff
from source. I expect stuff to not be 100% on 1.9, but my experience so far
is that 1.9 has caused me fewer and more easily fixable bugs than 1.8.7.

 

[Mike Gold]

[climbs to the top of the pile-up]

This is like an argument about what to do with the tricycle you rode as
a kid. Sure you may disagree about the current condition of the
tricycle, but really, who cares? You are grown up now. You can avoid
the issue entirely if you just stop riding the tricycle.

 

[David Masover]

Le 11 février 2009 à 22:53, Alex Fenton a écrit :

Something like :

require "compat-1.9"

Object.new.tap { |o| p o }

I guess that it's a lot of work if it's implemented in C,

I don't see why it would be -- wouldn't be the first C extension -- but
it's possbile I just don't understand the issue.

Regardless, many of these are just trivial.

class Object
def tap
yield self
self
end
end

class Symbol
def to_proc
proc {|x| self.send(x) }
end
end

There are a few, like public_send (which I really should be using there)
-- actually missing from 1.8.7, but I've actually got my own implemented
somewhere. In fact, the above don't really even need to be aware of
version numbers -- just something like:

unless Object.new.respond_to? :tap
class Object
def tap
...

unless :to_proc.respond_to? :to_proc
class Symbol
def to_proc
...

That would allow such libraries to be distributed as gems, and they'd do
no harm if run under 1.9 -- if there's already a C version in place, use
that, otherwise, add our own ruby version.

In fact, this is already how I develop things. I test on 1.8.7 and
1.9.1, but anything I build should work on 1.8.6 as well -- so far,
there's been nothing added to 1.8.7 that can't be added to 1.8.6 as
well, using plain old Ruby.