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

Ruby
1

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

2

On Feb 11, 2009, at 11:10 AM, Gregory B. wrote:

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.

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. 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. Thus I
feel we now have three different versions of Ruby 1.8 on the table
(counting the not yet released 1.8.8).

James Edward G. II

3

2009/2/11 Gregory B. [email protected]

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?

I’m not sure whose problem this really is, but it’s worth bearing in
mind
that in certain Linux package systems, there is just one ‘ruby1.8’
package
and one ‘ruby1.9’ package, each of which ships the latest from that
branch.
The same goes for the ‘gem’ executable, so you only get one gem repo per
‘major’ version – you don’t get a 1.8.6 gem repo and a 1.8.7 repo, you
just
get one for all 1.8.x releases.

Keeping 1.8.x back-compatible with prior 1.8.x seems like it would
minimise
confusion for a lot of people and reduce the burden of testing libraries
against multiple Rubys.

4

Gregory B. wrote:

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

Gregory - thank you for raising this here. I read this ruby-core thread:
http://www.ruby-forum.com/topic/178191#new

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”

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.

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 I won’t go on again. However one of the main reasons for allowing
1.8.7 to cherry-pick backports was that, at the time of the decision,
(Nov 2006) 1.9.1 seemed a while off, and some didn’t want the language
frozen until then. That seemed impatient to me then, but now there’s a
release version of 1.9.1 on the table, I can see no justifcation at all.

The progression to 1.9 isn’t that hard anyway; the language hasn’t
changed so much. And I can’t see that having a whole load of
incompatible 1.8.x mongrel releases washing about (as they end up in
distros etc) helps anyway.

Just to say again, I’m grateful for the work of the core developers and
maintainers - but it seems like 1.8 branch is being treated like a
personal playground rather than a stable version. There’s not even a
statement of what features might be backported.

Ooops, I’ve gone on at length again.

Anyway, +1 for Ruby 1.8.8 being a bugfix release implementing the same
API as 1.8.6

alex

5

I’ll write two posts.

Now that 1.9.1 is released, hopefully people will start porting to it,
and 1.8 can remain stable. For the people who still need all their old
gems to work, there should be a stable version – apparently, 1.8.7
broke a lot of things.

On top of which, if 1.8.8 is an easier upgrade than 1.9, people won’t be
as encouraged to port to 1.9.

6

+1

1.8 should keep its final branch release as fully 1.8 compatible for
posterity. (Keep it legacy compatible)
Ventures into the future can take place inside the Newer 1.9 and 2.0
branches without breaking what we could call “1.8 Legacy” code.

2009/2/11 James G. [email protected]

7

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.

  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 P.ming 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?

  4. Since I don’t personally have a large installed base of Ruby code,
    I am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
    documentation, performance tune, etc.
    –
    M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.

8

I wrote it on ruby-core and I write it again: I’m very worried and
confused with Ruby versioning policy.
I’m very unhappy with all 1.8.7 and possibly 1.8.8 version.

+1

–
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog

9

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.

  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 P.ming 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?

  4. Since I don’t personally have a large installed base of Ruby code, I
    am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
    documentation, performance tune, etc.
    –
    M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.

10

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.

  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 P.ming 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?

  4. Since I don’t personally have a large installed base of Ruby code,
    I am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
    documentation, performance tune, etc.
    –
    M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.

11

+1

#include

–
Aaron T.
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
Windows
Those who would give up essential Liberty, to purchase a little
temporary Safety,
deserve neither Liberty nor Safety.
– Benjamin Franklin

12

I’m very unhappy. Come on people! Use standard versioning:

1.MAJOR_VERSION.MINOR_VERSION

Should mean that after each MINOR_VERSION change I won’t loose
compatibility of my code, and only known bugs will be fixed or
performance improved! Backporting is unnecesary and confusing. Most
people will stay on 1.8.6 (including me on my servers) until most of
applications will work with 1.9.1.

Leave alone 1.8 branch, don’t do such stupid things like You want to!!

+1 is not enough!
+666! ;}

13

As a new Ruby user coming to the language, I’ve found it fairly
confusing as to which Ruby I should be using. I understand that 1.8.6
via Pickaxe is a standard and so is 1.9.1 via David Black’s upcoming
book.

Coming from other projects, it would seem to me that making changes to
1.8.x that aren’t backwards compatible is a confusing message. I don’t
like the idea of have parts of 1.8.x incompatible with the rest of it.
Thats nonsense.

+42 for not breaking backwards compatibility. 1.8.x made it this far,
no need to introduce changes that are already in place in 1.9.x.

-Zac

14

At work, we’ve already been bitten by 1.8.6 -> 1.8.7 problems.
I can’t tell you how much I don’t want to see 1.8.8 move even
further away from 1.8.6.

Please, leave the 1.8 line as compatible as possible, leave
the API breakage to the 1.8 -> 1.9 migration.

15

+1

I had a brief foray into 1.8.7 and had problems deploying code to some
servers that were running 1.8.6 so now use 1.8.6.

Will switch to 1.9.x when all the stuff I need works with it, but
until then I’d really appreciate a proper and consistent 1.8.x branch
that didn’t diverge into being a halfway house.

Backported stuff isn’t what I want at all - when I want 1.9.x features
(and everything works with them) I’ll move to 1.9 but please leave 1.8
alone!

Rupert

16

On Thu, 12 Feb 2009, M. Edward (Ed) Borasky 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.

Yeah, look what it did to Forth.

– Matt
It’s not what I know that counts.
It’s what I can remember in time to use.

17

Now that 1.9.1 is released, hopefully people will start porting to it,
and 1.8 can remain stable. For the people who still need all their old
gems to work, there should be a stable version – apparently, 1.8.7
broke a lot of things.

If it has to use parts of the new parser, can it use Ripper??

18

On Wed, Feb 11, 2009 at 2:47 PM, Matt L. [email protected]
wrote:

On Thu, 12 Feb 2009, M. Edward (Ed) Borasky 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.

Yeah, look what it did to Forth.

Don’t just say it, show it.

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

-greg

19

Gregory B. 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

+1

20

Matt L. wrote:

On Thu, 12 Feb 2009, M. Edward (Ed) Borasky 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.

Yeah, look what it did to Forth.

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!

–
M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.