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

Ruby
21

On 11 Feb 2009, at 19:55, Gregory B. wrote:

Yeah, look what it did to Forth.

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

raise ArgumentError unless @reality.responds_to? :reason

22

On Wed, Feb 11, 2009 at 6:10 PM, Gregory B.
[email protected] wrote:

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

23

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
24

On Feb 11, 2:04 pm, “M. Edward (Ed) Borasky” [email protected] wrote:

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

25

On Wed, Feb 11, 2009 at 12:10 PM, Gregory B.
[email protected]wrote:

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.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

26

On 11.02.2009 18:27, James G. wrote:

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

27

On Wed, Feb 11, 2009 at 1:42 PM, M. Edward (Ed) Borasky
[email protected]wrote:

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.

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.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

28

2009/2/11 Rick DeNatale [email protected]:

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

29

On Feb 11, 2009, at 3:42 PM, Pit C. wrote:

2009/2/11 Rick DeNatale [email protected]:

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.

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 G. II

30

Pit C. wrote:

2009/2/11 Rick DeNatale [email protected]:

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.

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

31

On Wed, Feb 11, 2009 at 4:13 PM, Robert K.
[email protected]wrote:

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?

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.

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.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

32

On Wed, Feb 11, 2009 at 4:53 PM, James G.
[email protected]wrote:

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.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

33

2009/2/11 Alex F. [email protected]:

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

34

2009/2/11 Rick DeNatale [email protected]:

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

35

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

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

36

M. Edward (Ed) Borasky wrote:

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.

37

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

38

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

39

2009/2/11 Pit C. [email protected]

2009/2/11 Rick DeNatale [email protected]:

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.

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.

40

On Wed, Feb 11, 2009 at 6:44 PM, Mike G. [email protected]
wrote:

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

You’re right. So then perhaps the whole 1.8 series should be
end-of-lifed. I’d be fine with that.
But Ruby 1.8.7 is more like thaking the old tricycle out and putting a
car engine on it.

Cute, but not a very useful tricycle or car at that point.

-greg