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.
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.
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###.
+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…
On Thu, Feb 12, 2009 at 11:07 AM, Gregory B. [email protected] wrote:
1.8.7 and beyond, those who like the idea will not be left
disappointed.
But that still leaves a communication gap between two groups of
implementers – Engine Y. and “Ruby-Core” – and the Linux distros
that are probably only going to package one Ruby and are expecting their user base to have working Ruby and Rails and gems! Right now,
I’m running openSUSE 11.1, which ships 1.8.7. IIRC RHEL 5 / CentOS 5
are still shipping 1.8.5, and I have no idea what’s in the two most
recent versions of Ubuntu, or what’s going to be in Debian Lenny when
it releases in the near future. In short, the distro Ruby herds need
to be in the loop, or the Ruby community will have a bunch of
implementations to choose from.
On Feb 12, 4:13 pm, “M. Edward (Ed) Borasky” [email protected] wrote:
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
I’ll like to jump late on this thread, but just not trying to add more
noise…
Thanks!! Yes, I think you’d be ideal for this. I do have some questions, though:
Would there be a chance of merging the efficiencies of Ruby
Enterprise Edition, especially copy-on-write friendliness, into the
“Engine Y. 1.8.6 stack?”
CoW will not be cross-platform compatible (at least not for Windows).
The amount of changes needed by CoW are so big because the C code of
Ruby sometimes can be complicated.
Will this impact Rubinius?
I hope not, and I think it wouldn’t.
Will there be a contribution to the Windows One-Click Installer
project as part of this?
I wish they do, or at least merge contributions back
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.
Yeah, I think I understand you, too. Of course you could develop right
away in 1.8.7 without using the new features. This code should still
work with 1.8.6. But it would require you to always think about this
necessity, and you would have no immediate feedback when you
accidentally used one of the new features.
I apologize for using vague terminology about ‘1.8’, it’s probably the
main source of dispute here.
There’s absolutely no reason to apologize, Greg. To me the main source
of dispute was that so many people were telling “1.8.7 breaks
compatibility with 1.8.6” but almost no none could prove this.
Just one more remark to Joel’s post, and then I’ll definitely shut up.
There’s absolutely no reason to apologize, Greg. To me the main source
of dispute was that so many people were telling “1.8.7 breaks
compatibility with 1.8.6” but almost no none could prove this.
That is a very good point. My issues however are much more of a
practical or psychological reason
The pure fact that incompatibilities exist, however small, will
certainly not assure me about BW (8.7 → 8.6 )compatibility for future
releases and neither for FW(8.6->8.7+).
That’s why I voted on this thread and not the other one.
I felt that Greg somehow was very much anticipating trouble rather
than seeing it around already. I was quite impressed by that vision,
but that of course does not mean that he/we is/are correct :).
In message “Re: If you are unhappy with the direction of Ruby 1.8.7+,
respond”
on Fri, 13 Feb 2009 02:10:41 +0900, Stefan L. [email protected] writes:
|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).
I think he relied on the version/implementation specific behavior, so
1.8.7 HELPED to find a bug in HIS code, unless I am wrong in any ways.
Any other example of 1.8.7 incompatibility?
I am not happy with FUD-like attitude against 1.8.7. From my point of
view, 1.8.7 is a good release with unfortunate beginning. There are
slight incompatibility, but every past releases also had some sort of
incompatibilities as well. I’d like to use 1.8.7 to write new 1.8
code.
It might be true that number of “enterprisey” Ruby users have grown
beyond our expectation, and we might need to keep “maintained stable
snapshot of the past version”, which happen to be 1.8.6, for existing
code base, that’s OK. We ARE keeping. If we want to keep it after
1.8.8 is out (in whatever state), we will need a volunteer to replace
Shyouhei.
EngineYard raised their hands for 1.8.6 maintainer. It’s OK. I am
not sure when we pass the role, now or future. In any case, we have
to discuss 1.8.6 maintenance policy. Let’s move to ruby-core.
Hashes aren’t ordered at all in 1.8, as far as I know.
I realise that there is no explicit iteration order specified for hashes
in
1.8. All I know is that this patch fixed by 1.8.7 bugs:
Basically involves inserting keys in an explicit order rather than using
hash literals. This project uses a bunch of custom collection classes
but
they’re basically wrappers for arrays and hashes that merge array and
hash
functionality into a single class. The constructors would iterate over
the
hashes provided and insert values, and this insertion order changed in
1.8.7.
I would concede that this is something of a grey area as it’s neither a
bug
fix or an explicit feature addition, but the question was asked about
1.8.6
code that broke, and this is an example. I still have a regex-related
bug in
this project that I’ve been unable to fix under 1.8.7. In fact, if
anyone is
able to fix the last remaining test failure I’d be incredibly grateful.
Engine Y. 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.
An order for Hash instances? Hash doesn’t define a <=> method.
the patch).
Hashes aren’t ordered at all in 1.8, as far as I know.
I realise that there is no explicit iteration order specified for hashes in
1.8. All I know is that this patch fixed by 1.8.7 bugs:
Sorry, I misunderstood what you were getting at.
fix or an explicit feature addition, but the question was asked about 1.8.6
code that broke, and this is an example. I still have a regex-related bug in
this project that I’ve been unable to fix under 1.8.7. In fact, if anyone is
able to fix the last remaining test failure I’d be incredibly grateful.
I can’t get any of your tests to fail under 1.8.7, at least the one
I’ve got installed on the machine where I tried it (pl0).
This is trivial to prove. This code:
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.
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
+1
Mr. Coglan seems not to understand how a hash-table is implemented.
One cannot predict the iteration order because he cannot know in which
bucket each element has been stored. Furthermore, it makes no sense
at all to be concerned about iteration-order for a hash-table.
If one is concerned about iteration-order, he should use an
association-list.
An element is fetched a hash-table by key, not by position,
which is undefined.
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
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
At Fri, 13 Feb 2009 09:16:39 +0900,
James C. wrote in [ruby-talk:327995]:
1.8.7.
Hash in 1.8 doesn’t define any kind of “order”. It’s
definitely a bug in your code as you use the word “order”.
I would concede that this is something of a grey area as it’s neither a bug
fix or an explicit feature addition, but the question was asked about 1.8.6
code that broke, and this is an example. I still have a regex-related bug in
this project that I’ve been unable to fix under 1.8.7. In fact, if anyone is
able to fix the last remaining test failure I’d be incredibly grateful.
