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

Greg_Brown1 · 11 February 2009 17:10

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

James_Edward_Gray_II · 11 February 2009 17:27

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

···

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

James_Coglan2 · 11 February 2009 17:34

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.

···

2009/2/11 Gregory Brown <gregory.t.brown@gmail.com>

Alex_Fenton2 · 11 February 2009 17:38

Gregory Brown wrote:

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

David_Masover · 11 February 2009 17:54

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.

M_Edward_Ed_Borasky2 · 11 February 2009 18:42

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.

Aaron_Turner · 11 February 2009 18:53

+1

#include <all the other comments so far>

···

--
Aaron Turner
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

Zac_Brown · 11 February 2009 19:00

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:

Sam2 · 11 February 2009 20:04

Gregory Brown wrote:

+1

Charles_Oliver_Nutte · 11 February 2009 20:15

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

Forum · 11 February 2009 20:16

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

···

On Wed, Feb 11, 2009 at 6:10 PM, Gregory Brown <gregory.t.brown@gmail.com> wrote:

Rick_DeNatale1 · 11 February 2009 21:01

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

···

On Wed, Feb 11, 2009 at 12:10 PM, Gregory Brown <gregory.t.brown@gmail.com>wrote:

--
Rick DeNatale

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

7rans · 11 February 2009 23:03

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

Mike_Gold · 11 February 2009 23:44

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

···

--
Posted via http://www.ruby-forum.com/.

thbar · 12 February 2009 00:29

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

Brian_Candler · 12 February 2009 09:03

Gregory Brown wrote:

...

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

···

--
Posted via http://www.ruby-forum.com/\.

Wayne_Walker · 13 February 2009 03:57

Gregory Brown wrote:

It is absolutely wrong to change major API and syntax within a major
release series.

1.8.8 should definitely go back to 100% syntactical and regression test
compatability with 1.8.6

Wayne

···

--
Posted via http://www.ruby-forum.com/\.

Uwe_Kubosch1 · 14 February 2009 01:41

+1

···

--
With kind regards,
Uwe Kubosch
Kubosch Consulting
Norway

Alan · 14 February 2009 18:03

+1000

We have a reasonable-sized body of code on 1.8.7, in production, that
we will not expect to upgrade for a minor release.

We expect _some_ compatibility issues with an 1.8 -> 1.9 upgrade.

We expect there will be many issues with an 1.8 -> 2.0 upgrade.

I have been developing software and managing the development process
for almost 30 years, and this issue of an incompatible minor release
is a huge violation of the Principle of Least Surprise.

If this trend is followed, that of capriciously breaking compatibility
on minor point releases, then the language usage rate will diminish,
adoption rate will decrease, and the language will become
marginalized.

People only have so much time and effort to work on problems. A
programming language is a tool to solve those problems. If the tool
causes MORE work, then another tool will be chosen instead.

It's really pretty simple.

···

On Feb 11, 12:10 pm, Gregory Brown <gregory.t.br...@gmail.com> wrote:

Nobuyoshi_Nakada1 · 15 February 2009 05:20

Hi,

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory Brown wrote in [ruby-talk:327704]:

Could anyone summarize compatibility issues which really exist
now?

···

--
Nobu Nakada

Topic		Replies	Views
If you are happy with the direction of Ruby 1.8.7+, respond ruby-talk	30	173	16 February 2009
Time to back peddle? (Ruby 1.8.7) ruby-talk	15	125	3 December 2008
Ruby 1.8 ruby-talk	0	84	14 February 2003
Ruby 1.8.4 released ruby-talk	8	118	28 December 2005
[ruby-list:43074] Ruby 1.8.5-p12 released ruby-talk	3	122	4 February 2007

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

Related topics