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

[Gregory Brown]

[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

 

[M. Edward (Ed) Borasky]

The process of ANS standardization decimated the Forth community

I don't think that's the case. What "decimated" the Forth community
was the emergence of microprocessors powerful enough to run languages
other than Forth and usable optimizing compilers for the C language
for less-powerful microprocessors that previously could only be
effectively programmed in Forth. Yes, the standardization process was
contentious, and I have no doubt Ruby's will be as well. But I think
it's something the community needs to do. Maybe the outcome of this
thread / discussion will be to establish an on-line "standards
committee".

 

[Urabe Shyouhei]

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?

This can of course be avoided if someone else follows me to continue supporting
1.8.6. Merging back upper stream changes into 1.8.6 is actually easy; it is an
automated process and you do not have to write C until "svn merge" conflicts
something. The harder part is to decide which one to merge.

 

[M. Edward (Ed) Borasky]

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

That's exactly *my* plan, but I don't have legacy Rails apps or large
RSpec test suites to maintain.

 

[Thibaut Barrère]

Hi Greg et al,

I'd really love to have only 1.8.6 (or compatible) then 1.9.x.

Having more seems like a waste of efforts and will (I'm afraid) make
it more difficult to ensure various plugins/gems do work properly. As
a consequence the ruby/rails/merb etc applications maintainers will
meet more trouble.

+1 for 1.8.x staying compatible with 1.8.6, absolutely.

-- Thibaut

 

[Michal Suchanek]

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.

+1

 

[M. Edward (Ed) Borasky]

+1

I haven't checked Fedora recently, but openSUSE 11.1 ships Ruby 1.8.7 as well.

 

[Michal Suchanek]

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.

That's completely fine but then mark the bright new idea as such, not
as a version of a dead-end product. It will do good service to both
the bright new idea and the dead-end product if they are labeled
correctly.

Thanks

Michal

 

[Alex Fenton]

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.

That's the point: library authors should be able to write against a
'stable' version of the language, without fearing that a Ruby branch
maintainer is going to happen to fancy to add a clashing method.

As a library author, it's fair to ask me to track pre-release versions
of 1.9, if I want to ensure timely compatibility with that. But it's not
reasonable to ask me to track changes on a 'stable' branch.

As for the C extensions: do you have more information about what was
changed in the Ruby internals that lead to those problems?
http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645


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.

A folly repeated is not a folly reduced. I've suffered from this before
1.8.5 -> 1.8.6, and been critical of it before.

I guess that 1.8.7 has just happened to make the silliness of adding a
random pot-pourri of features more apparent to more people.

alex

 

[Alex Fenton]

But what if they want to waste their energy there?

Then they have picked the wrong place for their energies. People should
be branch maintainer because they have pride in good engineering, not to
acquire a private laboratory for what they think are 'cool' features.

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.

People - including me - do, on many open-source projects. Of course it
is a bit boring to have to work with old structures, when the future can
be seen. But people do so because they see it's important work to give
confidence in the broader project.

If someone thinks it's *so* boring, then they should work on the
bleeding edge, not become "stable" maintainer. I'd rather 1.8 stagnate
than change so randomly.

a

 

[Bill Kelly]

As I remember it, Matz didn't want to have a version number like 1.8.10

For what it's worth, my recollection is that matz wasn't
_conceptually_ opposed to it, but rather it was not considered
acceptable to break the existing code in the field which performed
version checks based on string compares:
=> true
=> false


Regards,

Bill

 

[Joel VanderWerf]

For what it's worth, my recollection is that matz wasn't
_conceptually_ opposed to it, but rather it was not considered
acceptable to break the existing code in the field which performed
version checks based on string compares:

=> true

=> false

I remember that... did anyone ever suggest other number bases?

irb(main):001:0> "1.8.9" > "1.8.8"
=> true
irb(main):002:0> "1.8.A" > "1.8.8"
=> true

Nah, too weird!

 

[Urabe Shyouhei]

Then they have picked the wrong place for their energies. People should
be branch maintainer because they have pride in good engineering, not to
acquire a private laboratory for what they think are 'cool' features.

I don't intend to attack but for instance _why hasn't been touching his yaml
stdlib for years, in spite of yaml bugs continuously reported. If _why had
such pride you say, can that be possible?

Again, I'm not attacking _why. It's a nature of geek being that they get
interested in a new thing than old ones. Some people like you may be able to
maintain existing codes, but not everyone. Do not expect others to behave as
you do.

People - including me - do, on many open-source projects. Of course it
is a bit boring to have to work with old structures, when the future can
be seen. But people do so because they see it's important work to give
confidence in the broader project.

Of course not everyone ignore bugs. In fact most bugfixes aren't possible
without many helps of core developers. It's hence important for us not to
prevent core people to pray with Ruby. Bugfixes and new features are both
sourced from a developer brain and are dripped into Ruby 1.8 source code
altogether. To filter bugfixes only isn't easy, palming off that job to them
should drastically decrease their amount of output. That shouldn't make us happy.

If someone thinks it's *so* boring, then they should work on the
bleeding edge, not become "stable" maintainer. I'd rather 1.8 stagnate
than change so randomly.

I suspect that's why no one but me is touching 1.8.6 now.

 

[Phlip]

I don't intend to attack but for instance _why hasn't been touching his yaml
stdlib for years, in spite of yaml bugs continuously reported. If _why had
such pride you say, can that be possible?
+1

Again, I'm not attacking _why. It's a nature of geek being that they get
interested in a new thing than old ones. Some people like you may be able to
maintain existing codes, but not everyone. Do not expect others to behave as
you do.

I expect people to unit test their libraries and leave them open for others to
fix. YAML can't recover from syntax errors, can't accurately report them, and
experiences a stray pointer bug when it tries. Yes the lexer is awesome, but
libyaml is riiiight around the corner...

I suspect that's why no one but me is touching 1.8.6 now.

I do 1.8.6, and so does my shop.

 

[Justin Collins]

I remember that... did anyone ever suggest other number bases?

irb(main):001:0> "1.8.9" > "1.8.8"
=> true
irb(main):002:0> "1.8.A" > "1.8.8"
=> true

Nah, too weird!

I was looking at Erlang the other day.
On the front page of erlang.org:

"Erlang/OTP R12B-5 released*"*



-Justin

 

[Brian Candler]

I am setting up two threads ...
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'.

I think it's too late to go back now, but +1 to wishing 1.8.7 had never
existed. It causes all sorts of confusion even on this mailing list as
to what features do or do not exist in ruby 1.8, and gives admins an
unnecessary dilemma: upgrade all production boxes to new and relatively
untested code which may break existing applications? Or suffer the
complaints from new applications which start to rely on the new
features?

This was all handled much better in the 1.6 -> 1.8 transition.

* 1.6 was stable
* 1.7 was developmental, and added a bunch of features
* finally it was released as 1.8
* there was no meddling with 1.6
* A separate "shim" library was released which included a number of
useful new features from 1.8 (e.g. StringIO), which allowed some code
written using 1.8 features to run under 1.6, thus extending the lifetime
of 1.6

Under this model: 1.9 would have been experimental, it would have been
released eventually as 1.10 (or as 2.0, I don't care). 1.8 would have
been a stable production branch, and for those people who wanted
1.10/2.0 features, there would be an optional compatibility library.

As for numbering, it's not so important, but the current scheme is silly
and appears to be based on an irrational fear of exceeding 1.9. AFAICT,
this is either because the string "1.10" doesn't sort after "1.9", or
because 2.0 would somehow imply the language is especially "blessed" or
"finalised".

On that basis, 2.0 will never be released. IMO, YARV was a big enough
change to warrant a new major number. If you want to see numbering done
properly, look at FreeBSD's release process.

Anyway, I look forward to running ruby version 1.9.9.9 in future years

 

[Charles Oliver Nutter]

For what it's worth, my recollection is that matz wasn't
_conceptually_ opposed to it, but rather it was not considered
acceptable to break the existing code in the field which performed
version checks based on string compares:

=> true

=> false

I remember the discussions. I stand by my assertion that this is a bug.

- Charlie

 

[Ollivier Robert]

last night, and in particular Akinori MUSHA's statement:

"Yes. Backporting syntactic changes is a big part of the plan for ruby
1.8.8"

It boggles the mind to read that. I have an enormous respect for you
Akinori-san for both your FreeBSD and Ruby work but that's poppycock.

Luckily I was in bed else I'd have fallen off my chair. This seems to me
the most bonkers development plan I've seen in a long while.

Stable releases are meant to be *stable*; minor point releases are meant
to be *API compatible*, backwards and forwards. I can't think of any
other serious open-source project that would even contemplate adding
random bits of syntax and API calls in minor releases.

+1000

I feel 1.8.7 is the biggest mistake the Ruby developers have made, it muddies
the water about what are 1.8 and 1.9 (as if the problem about 1.9 not being
ruby2 or rite or whatever it is called was not enough!), don't encourage
people to move over to 1.9 at all.

I also think this is an software engineering mistake as well. You *never*
introduce API or language changes in a stable branch, ever. Worse, it was done
in a *minor* revision. What are you guys smokin'?

We don't need any glibc-like crazyness in Ruby, thanks. It is already
difficult enough to advocate Ruby over Python already with the almost non
existent Unicode/UTF-8 support (and quirky when something exist)...

I also think m17n is way too complicated in 1.9 but that's another windmill to
fight for.

I expressed the same opinion at length and with some fervour regarding
the release of 1.8.7: http://www.ruby-forum.com/topic/150251#663291

So did I, several times.

Sorry for ranting but seeing my favorite language go these ways is taking on
me.

 

[Ollivier Robert]

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.

Following a ticket I opened a few weeks ago, someone has created a ruby186
port.

 

[Yossef Mendelssohn]

0

I remember the discussions. I stand by my assertion that this is a bug.

I don't know about the discussions relating to this behavior, but I
find it dismaying that anyone would seriously say that this isn't
desired string comparison behavior. I mean, these are *strings*, not
anything special. They just happen to contain a certain pattern of
characters.

Or maybe you meant the bug was that people were comparing strings at
all, which is understandable (though a strange word choice).

Maybe we should start up the Perl v-string[1] debates in the Ruby
community. Actually, if Ruby core (or stdlib) had v-strings, that
would be a part of rubygems that could by set free from its cold, dark
p4 prison.


[1]: For a good time: http://search.cpan.org/~ferreira/Data-VString-0.00000=
4/lib/Data/VString.pm