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

ruby-talk
21

+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 Gray <james@grayproductions.net>

On Feb 11, 2009, at 11:10 AM, Gregory Brown 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 Gray II

22

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

23

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 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?

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.

24

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 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?

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.

25

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.

···

On Wed, Feb 11, 2009 at 12:00 PM, Zachary Brown <zac@zacbrown.org> wrote:

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

On Feb 11, 2009, at 12:10 PM, Gregory Brown 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'. 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

--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

--
thanks,
-pate
-------------------------
   Duty makes us do things, Love make us do things well.

26

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??

27

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.

···

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.

28

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.

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

···

On 11.02.2009 18:27, James Gray wrote:

On Feb 11, 2009, at 11:10 AM, Gregory Brown wrote:

29

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.

···

On Wed, Feb 11, 2009 at 1:42 PM, M. Edward (Ed) Borasky <zznmeb@gmail.com>wrote:

--
Rick DeNatale

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

30

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

···

2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:

Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

31

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.

32

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

···

On Wed, Feb 11, 2009 at 6:44 PM, Mike Gold <mike.gold.4433@gmail.com> 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.

--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

33

Charles Oliver Nutter wrote:

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.

34

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

···

On Wed, Feb 11, 2009 at 3:03 PM, Trans <transfire@gmail.com> wrote:

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

--
M. Edward (Ed) Borasky

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

35

+1

···

On 11/02/2009, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

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.

36

In article <Y2Ekl.10025$cg.1125@newsfe24.ams2>,

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.

···

Alex Fenton <alex@deleteme.pressure.to> wrote:
--
Ollivier ROBERT -=- CND/COE/VI/SQ -=- EUROCONTROL
Systems Quality & Support

37

In article <deb2337a0902111303o7a281d6bw1b7368db82b83864@mail.gmail.com>,

···

Rick DeNatale <rick.denatale@gmail.com> wrote:

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.
--
Ollivier ROBERT -=- CND/COE/VI/SQ -=- EUROCONTROL
Systems Quality & Support

38

I have no problems with the 1.9 release. I feel like the reasoning has been well explained and I understand it.

Essentially, a lot was promised for 2.0. About half of it has been built. We could have kept waiting for the other half, or release what was done. It's not all of 2.0 though, so it's instead called 1.9.

Also, it was decided that it's silly to lose an entire branch for development (like 1.7). Thus x.x.0 now means development and we only lose one version number. That's why 1.9.1 is the first stable release of the 1.9 branch.

I feel like that all makes sense.

James Edward Gray II

···

On Feb 12, 2009, at 3:03 AM, Brian Candler wrote:

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

39

+1, because things have broken.

I am happy with 1.8.6 and 1.9. It's just that 1.8.7 introduces a lot
of noise, anyone would expect it to be compatible with 1.8.6, as
mentioned.

40

+1 for the main question,
but...

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

I also agree about this. Perhaps it isn't too late
to rename "1.9.1.0.0.1" to "2.0.0.0.1" ??

Also is it possible to make some "ruby20.rb" package
wich emulate some features of 1.9 present in 1.8.7?

Then in ruby-1.8.8 which would be 1.8.6 like
but would allow us to write:

   require 'ruby20'

Then all sugar features that are present in ruby 1.8.7
would be enable!
Perhaps this package could even be required from a 1.8.6
ruby version??

-- Maurice

P.S.
+1 for the original question :wink:

···

On Feb 11, 9:15 pm, Charles Oliver Nutter <charles.nut...@sun.com> wrote: