If you are unhappy with the direction of Ruby 1.8.7+, respond
Gregory Brown
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 Gray
> 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
James Coglan
2009/2/11 Gregory Brown <gregory...@gmail.com>
> 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.
Alex Fenton
> 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
Louis-Philippe
+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 <ja...@grayproductions.net>
David Masover
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.
Radosław Bułat
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
M. Edward (Ed) Borasky
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.
M. Edward (Ed) Borasky
M. Edward (Ed) Borasky
Daniel Dettlaff
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! ;}
--
Posted via http://www.ruby-forum.com/.
Aaron Turner
#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
Zachary Brown
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
Rupert Voelcker
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
pat eyler
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.
--
thanks,
-pate
-------------------------
Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com
Phlip
> 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??
Matt Lawrence
> 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.
Gregory Brown
> 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
Sam
> 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
>
+1
M. Edward (Ed) Borasky
> 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!
Eleanor McHugh
> On Wed, Feb 11, 2009 at 2:47 PM, Matt Lawrence
> <ma...@technoronin.com> 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
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
Charles Oliver Nutter
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
Robert Dober
<gregory...@gmail.com> 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
>
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
w_a_...@yahoo.com
> Matt Lawrence 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!
>
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.)
Rick DeNatale
On Wed, Feb 11, 2009 at 12:10 PM, Gregory Brown
<gregory...@gmail.com>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.
>
>
+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
Robert Klemme
> 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.
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
Rick DeNatale
On Wed, Feb 11, 2009 at 1:42 PM, M. Edward (Ed) Borasky <zzn...@gmail.com>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.
>
> 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.
Pit Capitain
> 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
Alex Fenton
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
Rick DeNatale
On Wed, Feb 11, 2009 at 4:13 PM, Robert Klemme
<short...@googlemail.com>wrote:
> On 11.02.2009 18:27, James Gray wrote:
>
>> 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.
>>
>
> 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.
>
> 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.
>
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.
James Gray
> 2009/2/11 Rick DeNatale <rick.d...@gmail.com>:
>> 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 Gray II
Rick DeNatale
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.
F. Senault
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
--
When you like music more than life, something's wrong
When you start sleeping as you drive, something's wrong
When you're favorite drink is thinner, something's wrong
When you're proud to be a sinner... (K's Choice, Something's wrong)
Pit Capitain
> 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
Serabe
> 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
Urabe Shyouhei
> 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.
Trans
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.
James Coglan
2009/2/11 Pit Capitain <pit.ca...@gmail.com>
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.
Mike Gold
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/.
David Masover
> Le 11 février 2009 à 22:53, Alex Fenton 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.
>>
>
> 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,
I don't see why it would be -- wouldn't be the first C extension -- but
it's possbile I just don't understand the issue.
Regardless, many of these are just trivial.
class Object
def tap
yield self
self
end
end
class Symbol
def to_proc
proc {|x| self.send(x) }
end
end
There are a few, like public_send (which I really should be using there)
-- actually missing from 1.8.7, but I've actually got my own implemented
somewhere. In fact, the above don't really even need to be aware of
version numbers -- just something like:
unless Object.new.respond_to? :tap
class Object
def tap
..
unless :to_proc.respond_to? :to_proc
class Symbol
def to_proc
..
That would allow such libraries to be distributed as gems, and they'd do
no harm if run under 1.9 -- if there's already a C version in place, use
that, otherwise, add our own ruby version.
In fact, this is already how I develop things. I test on 1.8.7 and
1.9.1, but anything I build should work on 1.8.6 as well -- so far,
there's been nothing added to 1.8.7 that can't be added to 1.8.6 as
well, using plain old Ruby.
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.
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
That's exactly *my* plan, but I don't have legacy Rails apps or large
RSpec test suites to maintain.
Thibaut Barrère
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
I haven't checked Fedora recently, but openSUSE 11.1 ships Ruby 1.8.7 as well.
Michal Suchanek
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
>> 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.
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
> 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?
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
Yukihiro Matsumoto
In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, respond"
on Thu, 12 Feb 2009 06:54:09 +0900, Alex Fenton <al...@deleteme.pressure.to> writes:
|> compatibility of 1.8.7 seems to be pretty good.
|
|Well, Rails. And many SWIG-based C-extensions - eg wxRuby.
We know the Rails issue (and solved), but could you elaborate on
issues with wxRuby and SWIG?
matz.
Alex Fenton
http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645
a
Bill Kelly
From: "Rick DeNatale" <rick.d...@gmail.com>
>
> 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:
>> "1.8.9" > "1.8.8"
=> true
>> "1.8.10" > "1.8.9"
=> false
Regards,
Bill
Joel VanderWerf
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!
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Urabe Shyouhei
>> 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.
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.
>> 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.
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 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
I remember the discussions. I stand by my assertion that this is a bug.
- Charlie
Ollivier Robert
Alex Fenton <al...@deleteme.pressure.to> wrote:
>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 -=- CND/COE/VI/SQ -=- EUROCONTROL
Systems Quality & Support
Ollivier Robert
Rick DeNatale <rick.d...@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.
Yossef Mendelssohn
wrote:
> Bill Kelly wrote:
>
> > From: "Rick DeNatale" <rick.denat...@gmail.com>
>
> >> 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:
>
> >>> "1.8.9" > "1.8.8"
> > => true
>
> >>> "1.8.10" > "1.8.9"
> > => false
>
> 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.000004/lib/Data/VString.pm
--
-yossef
F. Senault
> I mean, these are *strings*, not anything special. They just happen
> to contain a certain pattern of characters.
Any Ruby string can become special :
>> RUBY_VERSION = RUBY_VERSION.dup
(irb):5: warning: already initialized constant RUBY_VERSION
=> "1.8.6"
>> class <<RUBY_VERSION ; def <=>(b)
>> self.split(/\./).collect { |x| x.to_i } <=> b.split(/\./).collect { |x| x.to_i }
>> end ; end
=> nil
>> RUBY_VERSION.freeze
=> "1.8.6"
>> RUBY_VERSION < '1.8.10'
=> true
But not '1.8.10' > RUBY_VERSION, alas !
:)
Fred
--
The above also applies to "true" and "false" tests: there can be no
absolute truth, only subjective reality as perceived from an
existentialist paradigm.
(Tanuki in the SDM, on politically-correct coding)
Stefan Lang
> On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:
>
>> 2009/2/11 Rick DeNatale <rick.d...@gmail.com>:
>>>
>>> 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.
1.8.x releases always introduced new methods.
If Ruby releases were done how the mob here wants
them, we wouldn't have a single new method since
1.8.0 was released in 2003.
Important is backwards compatibility and Ruby 1.8.7
is backwards compatible. Nobody so far has shown
where 1.8.7 is not backwards compatible.
That Rails broke was their own fault. They extend core
classes, so clashes are to be expected. If they had
tested with an 1.8.7 release candidate, I'm sure they
could have worked out a solution with the 1.8 maintainers.
Stefan
Phlip
> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.
What a great way to lead people into your viewpoint!
> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.
require 'rubynode'
--
Phlip
Stefan Lang
>> Important is backwards compatibility and Ruby 1.8.7
>> is backwards compatible. Nobody so far has shown
>> where 1.8.7 is not backwards compatible.
>
> require 'rubynode'
From http://rubynode.rubyforge.org/:
"RubyNode is a library that allows read only access to Ruby's
internal NODE structure."
It's cool that such libraries exist, but AFAIK MRI's
internal AST is not part of its public API, much
less part of Ruby 1.8, the language.
Stefan
James Coglan
>
>
> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.
See my earlier demonstration:
git clone git://github.com/jcoglan/packr.git packr
cd packr
git co -b 3.1 origin/3.1
git co 4cc307
rake multi
No monkey-patching on my part, just existing 1.8.6 behaviour that changed in
1.8.7. I'm all for additions, as long as established behaviour is stable.
Additions should not break existing code if you're not monkey patching.
@_why I'm not interested in joining a mob and I'm not going to be mad at
Matz et al if they disagree with me. Just responding to a question, hope
none of this appears mob-like.
David A. Black
> 2009/2/11 James Gray <ja...@grayproductions.net>:
>> On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:
>>
>>> 2009/2/11 Rick DeNatale <rick.d...@gmail.com>:
>>>>
>>>> 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.
>
> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.
There's no mob. I wish people would stop using that word in this
thread. These are, to a large extent, friends of mine, and friends of
the core team members, discussing an exceptionally important Ruby
issue with ardency but with collegiality.
Much, much more has been said about the issues involved in the recent
version policy than that it's bad to introduce any new methods in
teeny versions (and that, as far as I can see, has *not* been said).
My main problem with it is that, while I understand the idea of 1.8.7
and 1.8.8 as stepping stones to 1.9.1, I don't think we need any
stepping stones. I've been learning 1.9 pretty intensely over the past
year, and I have never felt the need to have a 1.8 version that had
1.9 features. 1.9 has kept me quite busy.
I also love 1.8.6, and while I think a lot of 1.9 features are great,
I've never felt like I can't go another day (week, month, whatever)
without them.
So the whole backporting thing has been a puzzle to me. I think, in
any case, that there's no one thing (1.8.7 not running 1.8.6 code;
1.8.x ceasing to mean what a.b.x has generally meant in the past;
1.8.>6 leading to more, rather than less, trepidation about moving to
1.9; the issues with non-MRI implementations that Charlie and Evan
have talked about, etc.) responsible for the misgivings. It's a kind
of perfect storm of all these things.
I don't see any long-term way out of it except to focus on the move to
1.9.1. I don't mean that as a repudiation of anyone's work. It's my
assessment of where things stand, however they got there.
David
--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)
http://www.wishsight.com => Independent, social wishlist management!
Stefan Lang
>>
>>
>> Important is backwards compatibility and Ruby 1.8.7
>> is backwards compatible. Nobody so far has shown
>> where 1.8.7 is not backwards compatible.
>
>
>
> See my earlier demonstration:
>
> git clone git://github.com/jcoglan/packr.git packr
> cd packr
> git co -b 3.1 origin/3.1
> git co 4cc307
> rake multi
>
> No monkey-patching on my part, just existing 1.8.6 behaviour that changed in
> 1.8.7. I'm all for additions, as long as established behaviour is stable.
> Additions should not break existing code if you're not monkey patching.
It would be helpful to see exactly what fails.
Stefan
David A. Black
> Much, much more has been said about the issues involved in the recent
> version policy than that it's bad to introduce any new methods in
> teeny versions (and that, as far as I can see, has *not* been said).
A followup to this:
I think there are two important points to keep in mind. First, it's a
matter of degree, not kind. In other words, no one is saying that
1.8.7 should be indistinguishable from 1.8.6. It's more the quantity
of change that's at issue. Here's a very crude metric, showing the
results of instance_methods(false) for various classes and modules
across three 1.8 versions:
1.8.2
String: 83
Array: 71
Hash: 45
Range: 15
Enumerable: 22
1.8.6
String: 83
Array: 71
Hash: 45
Range: 15
Enumerable: 22
1.8.7
String: 91
Array: 83
Hash: 47
Range: 15
Enumerable: 43
(Gotta love Range :-)
Of course there's no cut-off point where it ceases to be good, or
whatever. It's a matter of judgment.
The second important point is that it's not so much a matter of 1.8.7
not running 1.8.6 code, as the degree to which people expect teeny
versions to behave the way they always have -- and that means, in the
main, developing 1.8.7 code and expecting no more than a few bug-fixes
and maybe the necessity to shim a couple of methods when running it on
1.8.6 installations.
I don't think there's any question about the fact that 1.8.7 redefined
the teeny method semantics, and that it all goes back to the 1.10
issue. And of course the numbering is arbitrary and human-made, and a
given sequence of digits isn't inherently better or worse than another
sequence. It's about expectations and how the changes, once made, play
out.
James Coglan
>
>
> > See my earlier demonstration:
> >
> > git clone git://github.com/jcoglan/packr.git packr
> > cd packr
> > git co -b 3.1 origin/3.1
> > git co 4cc307
> > rake multi
> >
> > No monkey-patching on my part, just existing 1.8.6 behaviour that changed
> in
> > 1.8.7. I'm all for additions, as long as established behaviour is stable.
> > Additions should not break existing code if you're not monkey patching.
>
> It would be helpful to see exactly what fails.
The cause of the failing tests is a change to Hash ordering between
versions. See the fix patch for a better idea:
http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849
Stefan Lang
What do you mean with "Hash ordering"?
An order for Hash instances? Hash doesn't define a <=> method.
Or iteration order of Hash elements? That wasn't defined
in 1.8.6 (I don't know if it is in 1.8.7).
Stefan
Ezra Zygmuntowicz
Engine Yard is willing to step up as the official maintainer of
ruby1.8.6. We can provide the right amount of human resources as well
as server and QA resources with automated CI running the rubyspecs.
I feel that it is very important to keep a stable ruby 1.8.6 lineage
for some time to come.
Matz has stated that he is willing to pass the torch on maintenance
of ruby1.8.6 and we would like to step up to the plate for the whole
ruby community. Please respond here if you think Engine yard would
make good maintainers of the ruby1.8.6 lineage
Thanks
Ezra Zygmuntowicz
e...@engineyard.com
Ola Bini
--
Ola Bini (http://olabini.com)
Ioke creator (http://ioke.org)
JRuby Core Developer (http://jruby.org)
Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
Practical JRuby on Rails (http://apress.com/book/view/9781590598818)
"Yields falsehood when quined" yields falsehood when quined.
Gregory Brown
I think that's a great idea. Restating what I said on ruby-core:
This would give those of us who need a stable legacy 1.8 to follow a
place to look for bug fixes and stablizations. We would be free to
choose whether we want to support this sort of next-generation Ruby
1.8 that ruby-core provides, and no matter what side of the fence
you're on, you can always follow Ruby 1.9.1 as well if you wish. In
my case, I'd likely be supporting EYRuby (or whatever you'll call it),
and Ruby 1.9.1 from the core team for my projects. Others could mix
and match as they please, but they will have the luxury of not having
to dig down into a single release of a branch that has diverged from
it. That's cool all around.
Just one question: Have you though about version numbering / naming
schemes yet?
-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
Rick DeNatale
+1
Although, I'm at a loss as to what you'd use for the version number on the
first maintenance release.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
Gregory Brown
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmo...@gmail.com>wrote:
>
>>
>> Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6. We can provide the right amount of human resources as well as
>> server and QA resources with automated CI running the rubyspecs.
> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.
Just a thought...
RUBY_VERSION #=> "1.8.6"
EY_RUBY_VERSION #=> "1.0.0"
-greg
pat eyler
Ezra, this would be an incredible step. Please, please do it.
>
> Thanks
>
> Ezra Zygmuntowicz
> e...@engineyard.com
>
>
>
>
>
--
thanks,
-pate
-------------------------
Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com
James Coglan
>
>
>
> What do you mean with "Hash ordering"?
> An order for Hash instances? Hash doesn't define a <=> method.
> Or iteration order of Hash elements? That wasn't defined
> in 1.8.6 (I don't know if it is in 1.8.7).
In 1.8.6, iteration order would be the same as the order that the keys
appear in the source. To work with 1.8.7, you need to create an empty hash
and add keys one by one rather than putting them all in a hash literal (see
the patch).
James Gray
> Although, I'm at a loss as to what you'd use for the version number
> on the first maintenance release.
1.8.6.1 perhaps? It still sorts well.
James Edward Gray II
Ola Bini
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmo...@gmail.com>wrote:
>
>
>> Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6. We can provide the right amount of human resources as well as
>> server and QA resources with automated CI running the rubyspecs.
>>
>> I feel that it is very important to keep a stable ruby 1.8.6 lineage
>> for some time to come.
>>
>> Matz has stated that he is willing to pass the torch on maintenance
>> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
>> community. Please respond here if you think Engine yard would make good
>> maintainers of the ruby1.8.6 lineage
>>
>>
>>
> +1
>
> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.
>
>
>
pat eyler
which probably means Ruby 1.8.6.1 or Ruby186 1.0
> -greg
David Masover
>
> Engine Yard is willing to step up as the official maintainer of
> ruby1.8.6. We can provide the right amount of human resources as well
> as server and QA resources with automated CI running the rubyspecs.
+1
Personally, I'd rather see a 1.9-compatible Merb, but it's looking like
I'll have to wait for Rails 3 for that.
James Gray
> 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".
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
David A. Black
On Fri, 13 Feb 2009, James Coglan wrote:
>>
>>
>>
>> What do you mean with "Hash ordering"?
>> An order for Hash instances? Hash doesn't define a <=> method.
>> Or iteration order of Hash elements? That wasn't defined
>> in 1.8.6 (I don't know if it is in 1.8.7).
>
>
>
> In 1.8.6, iteration order would be the same as the order that the keys
> appear in the source. To work with 1.8.7, you need to create an empty hash
> and add keys one by one rather than putting them all in a hash literal (see
> the patch).
Hashes aren't ordered at all in 1.8, as far as I know. This works the
same in 1.8.6 and 1.8.7:
irb(main):002:0> h = {3,4,1,2}
=> {1=>2, 3=>4}
irb(main):003:0> h.each {|*x| p x }
[[1, 2]]
[[3, 4]]
=> {1=>2, 3=>4}
and here's a 1.8.7 case with individual key insertion:
irb(main):001:0> h = {}
=> {}
irb(main):002:0> h[3] = 4
=> 4
irb(main):003:0> h[1] = 2
=> 2
irb(main):004:0> h.each {|*x| p x }
[[1, 2]]
[[3, 4]]
Stefan Lang
>>
>>
>>
>> What do you mean with "Hash ordering"?
>> An order for Hash instances? Hash doesn't define a <=> method.
>> Or iteration order of Hash elements? That wasn't defined
>> in 1.8.6 (I don't know if it is in 1.8.7).
>
>
>
> In 1.8.6, iteration order would be the same as the order that the keys
> appear in the source.
Iteration order is undefined, even for hash literals.
This is on *my* machine:
$ ruby -v -e '{2 => 0, 1 => 0}.each_pair { |k,v| p k }'
ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
1
2
Your code happened to work by chance.
> To work with 1.8.7, you need to create an empty hash
> and add keys one by one rather than putting them all in a hash literal (see
> the patch).
Do I understand that the code relies on insertion order now?
Then it's still working by chance in case it works at all.
Stefan
M. Edward (Ed) Borasky
Thanks!! Yes, I think you'd be ideal for this. I do have some questions, though:
1. Would there be a chance of merging the efficiencies of Ruby
Enterprise Edition, especially copy-on-write friendliness, into the
"Engine Yard 1.8.6 stack?"
2. Will this impact Rubinius?
3. Will there be a contribution to the Windows One-Click Installer
project as part of this?
4. Will there be some "community management" / "marketing" effort
associated with interfacing to the major Linux distros?
(Debian/Ubuntu, Fedora/Red Hat/CentOS, openSUSE/SLES/Novell for sure,
and probably Gentoo as well)
--
M. Edward (Ed) Borasky
I've never met a happy clam. In fact, most of them were pretty steamed.
Gregory Brown
> On Thu, Feb 12, 2009 at 10:39 AM, Gregory Brown
> <gregory...@gmail.com> wrote:
>> On Thu, Feb 12, 2009 at 12:36 PM, Rick DeNatale <rick.d...@gmail.com> wrote:
>>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmo...@gmail.com>wrote:
>>>
>>>>
>>>> Engine Yard is willing to step up as the official maintainer of
>>>> ruby1.8.6. We can provide the right amount of human resources as well as
>>>> server and QA resources with automated CI running the rubyspecs.
>>
>>> Although, I'm at a loss as to what you'd use for the version number on the
>>> first maintenance release.
>>
>> Just a thought...
>>
>> RUBY_VERSION #=> "1.8.6"
>> EY_RUBY_VERSION #=> "1.0.0"
>>
>
> which probably means Ruby 1.8.6.1 or Ruby186 1.0
Yeah, I think maybe 1.8.6.1 is a better idea than what I offered, actually.
Robert Dober
be in use for a long time yet.
Now I will not say to whomever is doing this great job on Ruby1.8 you
have to do this or that, I am not *that* stupid.
But those of us, who simply express their sincere opinion on the
subject should not be treated as a mob, or somebody too stupid to
follow to 1.9.1 neither, hopefully most of us agree with this?
Cheers
Robert
--
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov
Rubén Medellín
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.
Joel VanderWerf
> Joel VanderWerf wrote:
>> Bill Kelly wrote:
>>>
>>> From: "Rick DeNatale" <rick.d...@gmail.com>
>>>>
>>>> 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:
>>>
>>>>> "1.8.9" > "1.8.8"
>>> => true
>>>
>>>>> "1.8.10" > "1.8.9"
>>> => 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!
>>
>
> I was looking at Erlang the other day.
> On the front page of erlang.org:
>
> "Erlang/OTP R12B-5 released*"*
Someday, they'll get up to 27B-6.... (sorry, way too off-topic now).
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Rupert Voelcker
> Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage
That'd be great!
Rupert
Rick DeNatale
On Thu, Feb 12, 2009 at 12:54 PM, Ola Bini <ola....@gmail.com> wrote:
> Rick DeNatale wrote:
>
>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmo...@gmail.com
>> >wrote:
>>
>>
>>
>>> Engine Yard is willing to step up as the official maintainer of
>>> ruby1.8.6. We can provide the right amount of human resources as well as
>>> server and QA resources with automated CI running the rubyspecs.
>>>
>>> I feel that it is very important to keep a stable ruby 1.8.6
>>> lineage
>>> for some time to come.
>>>
>>> Matz has stated that he is willing to pass the torch on maintenance
>>> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
>>> community. Please respond here if you think Engine yard would make good
>>> maintainers of the ruby1.8.6 lineage
>>>
>>>
>>>
>>>
>> +1
>>
>> Although, I'm at a loss as to what you'd use for the version number on the
>> first maintenance release.
>>
>>
>>
>>
> What about 1.8.6.1?
>
As long as the downstream packagers pick up on it, but without additional
help, I think that most systems would treat 1.8.7 as compatible with, and
'better' than 1.8.6.x.
Examples.
Debian only uses the major and minor to differentiate different packages.
The Ubuntu list of Ruby packages illustrates this:
http://packages.ubuntu.com/search?keywords=ruby There are separate Ruby1.8
and Ruby1.9 packages.
Note that the newer Debian systems map Ruby1.8 to Ruby 1.8.7 they also seem
to use patchlevel and other information to generate their own fourth level
version numbers
Macports only seems to have s single Ruby which is currently at 1.8.7
>port list ruby
ruby @1.8.7-p72 lang/ruby
Considering how much trouble there's been reconciling the issues around
rubygems and debian, I'm not very confident that package maintainers will
treat 1.8.6.x and 1.8.7 as different upstream versions.
But I 'll reiterate that I think that the idea of maintaining 1.8.6 with
fixed semantics is a good idea.
pat eyler
> As long as the downstream packagers pick up on it, but without additional
> help, I think that most systems would treat 1.8.7 as compatible with, and
> 'better' than 1.8.6.x.
>
>
> But I 'll reiterate that I think that the idea of maintaining 1.8.6 with
> fixed semantics is a good idea.
Good points. I wonder what matz is willing to turn over. If it's the 1.8 line,
then the next release should probably be 1.8.8 and represent a
continuation of the 1.8.6 line. If he wants to maintain a 1.8.X and 1.9.X
line, then I think we need to think about either a 1.8.6.X or a RubyClassic
1.0 (or something like it)
>
> --
> Rick DeNatale
>
> Blog: http://talklikeaduck.denhaven2.com/
> Twitter: http://twitter.com/RickDeNatale
>
--
Nobuyoshi Nakada
At Fri, 13 Feb 2009 02:36:06 +0900,
Rick DeNatale wrote in [ruby-talk:327919]:
> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.
1.8.6-p###.
--
Nobu Nakada
Pit Capitain
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmo...@gmail.com> wrote:
>> Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6.
>
> This would give those of us who need a stable legacy 1.8 to follow a
> place to look for bug fixes and stablizations.
Gregory, there is no Ruby 1.8 and has never been. There have been
1.8.0, 1.8.1, up to 1.8.7, each one differing from the others. I'm
sure that for each new version you can find new methods introduced
and/or behaviour of existing methods changed. This was the point I
never understood: what's so special about the transition to 1.8.7?
I think what most of you really want is to keep 1.8.6, not some
ominous "Ruby 1.8", what ever this should be. Ezra has put this right:
"maintainer of 1.8.6".
So, you keep your 1.8.6, and others can go on to 1.8.7 and beyond. I
think this would be a perfect solution.
Regards,
Pit
Gregory Brown
> 2009/2/12 Gregory Brown <gregory...@gmail.com>:
>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmo...@gmail.com> wrote:
>>> Engine Yard is willing to step up as the official maintainer of
>>> ruby1.8.6.
>>> (...)
>>
>> This would give those of us who need a stable legacy 1.8 to follow a
>> place to look for bug fixes and stablizations.
>
> Gregory, there is no Ruby 1.8 and has never been. There have been
> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others. I'm
> sure that for each new version you can find new methods introduced
> and/or behaviour of existing methods changed. This was the point I
> never understood: what's so special about the transition to 1.8.7?
You keep saying this but frankly, it's ridiculous. Yes, you can find
changes. In Ruby 1.8.7, you get clubbed over the head with them.
> I think what most of you really want is to keep 1.8.6, not some
> ominous "Ruby 1.8", what ever this should be. Ezra has put this right:
> "maintainer of 1.8.6".
>
> So, you keep your 1.8.6, and others can go on to 1.8.7 and beyond. I
> think this would be a perfect solution.
We're not in disagreement here. It's just been my experience that I
can write code on 1.8.6 without thinking about back-wards
compatibility with earlier versions, for the most part. We all know
that things have changed, but not in so radical a fashion.
What I was supporting was a stable 'flavor' of Ruby 1.8, in the form
of a EY supported 1.8.6.
And I agree completely that this solves the issue without forcing
people in one direction or the other. If ruby-core wishes to support
1.8.7 and beyond, those who like the idea will not be left
disappointed.
Pit Capitain
> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.ca...@gmail.com> wrote:
>> Gregory, there is no Ruby 1.8 and has never been. There have been
>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>
> changes. In Ruby 1.8.7, you get clubbed over the head with them.
So we agree to disagree. Though I'd be interested in what you'd define
as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
will be 1.8.6, so why not name it as such? Why interpret more into it
as it really is?
> We're not in disagreement here. It's just been my experience that I
> can write code on 1.8.6 without thinking about back-wards
> compatibility with earlier versions, for the most part. We all know
> that things have changed, but not in so radical a fashion.
Hmm, let's see how radical a change 1.8.7 has been until now:
Hash#hash has been changed (or should I say: fixed), it's not allowed
to allocate new objects during garbage collection anymore (the SWIG
problem), plus (admittedly a large number of) new features have been
added. I wouldn't call this radical, but, again, we just disagree
here, so I'll shut up now.
Regards,
Pit
Tom Copeland
+1 on that. I never even consider downloading 1.8.7 or later for a
customer... I just grab the most recent 1.8.6-pxxx release. If p288
came out and didn't break anything, I'd start using that...
Yours,
tom
Gregory Brown
> 2009/2/12 Gregory Brown <gregory...@gmail.com>:
>> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.ca...@gmail.com> wrote:
>>> Gregory, there is no Ruby 1.8 and has never been. There have been
>>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>>
>> You keep saying this but frankly, it's ridiculous. Yes, you can find
>> changes. In Ruby 1.8.7, you get clubbed over the head with them.
>
> So we agree to disagree. Though I'd be interested in what you'd define
> as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
> a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
> will be 1.8.6, so why not name it as such? Why interpret more into it
> as it really is?
I understand what you mean here, and actually, you're right in saying
that the term "Ruby 1.8" is completely amorphous.
But I suppose what I'm saying is that from 1.8.2 up until 1.8.6, I did
not once say "Wow! now I can do all this new cool stuff!". I also
didn't worry too much about whether code I wrote on my latest Ruby 1.8
version would work in various out of date production environments. I
did not worry about patches from contributors having the same problem
in my open source projects.
The situation also might be different for me if 1.9 didn't exist. But
I'm not sure you'll agree with my reasoning on that, and it's not
terribly important anyway, so I won't elaborate further.
>> We're not in disagreement here. It's just been my experience that I
>> can write code on 1.8.6 without thinking about back-wards
>> compatibility with earlier versions, for the most part. We all know
>> that things have changed, but not in so radical a fashion.
>
> Hmm, let's see how radical a change 1.8.7 has been until now:
> Hash#hash has been changed (or should I say: fixed), it's not allowed
> to allocate new objects during garbage collection anymore (the SWIG
> problem), plus (admittedly a large number of) new features have been
> added. I wouldn't call this radical, but, again, we just disagree
> here, so I'll shut up now.
I think you're looking at this from the perspective of standalone Ruby
code, and I can see a bit of what you're saying from that perspective.
But I'm speaking based on my experience of having to deploy code to
older versions of Ruby in a commercial setting, as well as running
several mainstream open source projects that have an active
contributor base. It is possible that we're 'both right' in our own
situations, and that this solution of having EY run 1.8.6 might give
us the best of both worlds.
I apologize for using vague terminology about '1.8', it's probably the
main source of dispute here.
-greg