On Thu, Feb 12, 2009 at 12:36 PM, Rick DeNatale
[email protected] wrote:
On Thu, Feb 12, 2009 at 12:22 PM, Ezra Z. [email protected]wrote:
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.
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
On Feb 12, 2009, at 11:36 AM, Rick DeNatale wrote:
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 G. II
On Thu, Feb 12, 2009 at 10:39 AM, Gregory B.
[email protected] wrote:
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
Rick DeNatale wrote:
Matz has stated that he is willing to pass the torch on maintenance
What about 1.8.6.1?
–
Ola B. (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.
Ezra Z. wrote:
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.
+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.
Hi –
On Fri, 13 Feb 2009, James C. wrote:
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]]
David
–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
On Feb 12, 2009, at 3:03 AM, Brian C. wrote:
As for numbering, it’s not so important, but the current scheme is
silly
and appears to be based on an irrational fear of exceeding 1.9.
AFAICT,
this is either because the string “1.10” doesn’t sort after “1.9”, or
because 2.0 would somehow imply the language is especially “blessed”
or
“finalised”.
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 G. II
On Thu, Feb 12, 2009 at 9:22 AM, Ezra Z. [email protected]
wrote:
community. Please respond here if you think Engine yard would make good
maintainers of the ruby1.8.6 lineage
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?”
-
Will this impact Rubinius?
-
Will there be a contribution to the Windows One-Click Installer
project as part of this?
-
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.
On Thu, Feb 12, 2009 at 12:55 PM, pat eyler [email protected] wrote:
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.
-greg
I really feel that Ruby1.8.6 “deserves” more respect. It will probably
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
2009/2/12 James C. [email protected]:
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
+1, because things have broken.
I am happy with 1.8.6 and 1.9. It’s just that 1.8.7 introduces a lot
of noise, anyone would expect it to be compatible with 1.8.6, as
mentioned.
Justin C. wrote:
version checks based on string compares:
=> 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).
2009/2/12 Ezra Z. [email protected]:
Please respond here if you think Engine yard would make good
maintainers of the ruby1.8.6 lineage
That’d be great!
Rupert
On Thu, Feb 12, 2009 at 11:35 AM, Rick DeNatale
[email protected] wrote:
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.
[elided]
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)
Hi,
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###.
2009/2/12 Gregory B. [email protected]:
On Thu, Feb 12, 2009 at 12:22 PM, Ezra Z. [email protected] wrote:
Engine Y. 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
On Thu, Feb 12, 2009 at 12:54 PM, Ola B. [email protected] wrote:
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:
Ubuntu – Package Search Results -- 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.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
2009/2/12 Gregory B. [email protected]:
On Thu, Feb 12, 2009 at 1:59 PM, Pit C. [email protected] 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?
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
On Thu, Feb 12, 2009 at 1:59 PM, Pit C. [email protected]
wrote:
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.
-greg