Ruby 1.8.7-preview2 has been released

[Akinori MUSHA]

Folks,

Here is an announcement that the second preview of Ruby 1.8.7 has just
been released. Changes from the previous preview release include
several fixes for some incompatibility issues and bugs that have been
addressed by now.

Addition of Symbol#to_proc has been backed out, because it didn't work
as expected as intended in the test cases.

The new version of Ruby includes many bug fixes, lots of feature
enhancements and some performance improvements since 1.8.6 while
maintaining stability and backward compatibility with the previous
release to a high degree.

The source code package is available in three formats at the following
locations:

ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-preview2.tar.bz2
ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-preview2.tar.gz
ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-preview2.tar.zip

Checksums:

MD5 (ruby-1.8.7-preview2.tar.bz2) = aea3c408133a4a292198afa4b6b73af4
SHA256 (ruby-1.8.7-preview2.tar.bz2) = d02c1d22bff5c8365aa4adb25387950c0b58206a18cb18afcc4f2bd9401997e5
SIZE (ruby-1.8.7-preview2.tar.bz2) = 4013909

MD5 (ruby-1.8.7-preview2.tar.gz) = 776ca41fbc0b5c8d83c184cc79c3b622
SHA256 (ruby-1.8.7-preview2.tar.gz) = e969a88f91b26033e32f103e2db352d34a604c826789a1eb748fcb971fc9f602
SIZE (ruby-1.8.7-preview2.tar.gz) = 4714063

MD5 (ruby-1.8.7-preview2.zip) = b70c39942184101f6f3a9cd1eb245a12
SHA256 (ruby-1.8.7-preview2.zip) = 719ab45df2ca80bebf6e5e722778126f648e41a114d0d055a07837bb6fe55ee5
SIZE (ruby-1.8.7-preview2.zip) = 5797584

For a brief list of user visible changes and a full list of all
changes, see the bundled files named NEWS and ChangeLog, which are
also available at the following locations:

http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_preview2/NEWS
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_preview2/ChangeLog

Please test it out and drop us a report in the following tracker if
you find any problem:

http://rubyforge.org/tracker/?atid=22040&group_id=426&func=browse

Some known problems are on the list and when you find one it may be
fixed already, so please look through all items querying with "State"
set to "Any" before submitting a new one.

The next preview is planned on next Friday and that will hopefully be
the last preview release.

Regards,

 

[Alex Fenton]

Here is an announcement that the second preview of Ruby 1.8.7 has just
been released.
....

The new version of Ruby includes many bug fixes, lots of feature
enhancements
....


http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_preview2/NEWS
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_preview2/ChangeLog

Firstly, Akinori, thank you very much for your generous work on ruby.
The criticisms that follow are not at all directed at your work, but
rather at what seems a casual and ill-advised approach to branch
management in Ruby.

Even though this may well be a good release, it isn't a stable
development of the 1.8 series, but a hybrid of 1.8 with a random
selection of 1.9 features added in (many or most of which I like, in
their own right). But if I can't use 1.8.7 without unwittingly writing
code that's incompatible with every other released version of ruby, then
it's not a stable release.

This isn't just a hypothetical problem. The lax approach to stable
branch management has bitten me twice in the last 24 hours. I was using
Digest for the first time in a while; I couldn't remember exactly how
the module works, but using 1.8.6, I soon come up with:

require 'digest'
foo = Digest::SHA1(some_string)

Which works fine. Except, I realise today looking at the NEWS file, that
I've just written code which will break on every previous ruby version.
Did I want that? No - but how could I tell, except if I'd memorised
Ruby's CHANGELOG?

More seriously, I just tried out 1.8.7-preview2 with a large compiled
extension (wxRuby). What was a stable library in 1.8.6 now segfaults
regularly. Debugging GC/memory problems in a ruby extension is a
miserable job, but doubly so if you're chasing a moving target in a
supposedly stable series. Right now, I can't see any point in trying to
support 1.8.7.

Many or most open-source projects are strict about maintaining
compatibility within stable release series, and I don't understand why
ruby can't be. I think the desire to extend and improve the language is
great, but in the shorter term ruby provides many ways to test, use and
refine enhancements (facets, ActiveSupport) while maintaining some sense
of dependability in the core interpreter. I like Array#index { ... } but
I can live without it a few months longer.

Anyway, some of this reiterates what's been said elsewhere by others
[1]. It's been suggested in reply that only mission-critical application
developers and rigid corporate types care about stability within branches.

In fact, this sort of casual branch management imposes a cost borne by
ordinary users (who find libraries randomly don't work with the version
of ruby they happen to have installed) and average library developers
(who can't be sure that they are targetting more than a single
point-version, and end up fielding more support requests).

But, I guess that since there's a world shortage of new Integers between
8 and 9, there's no hope that this release could be given a more
appropriate version tag?

alex

[1] http://www.ruby-forum.com/topic/149772#new

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Fenton wrote:

|
| Firstly, Akinori, thank you very much for your generous work on ruby.

I second that motion.

| Anyway, some of this reiterates what's been said elsewhere by others
| [1]. It's been suggested in reply that only mission-critical application
| developers and rigid corporate types care about stability within branches.
|
| In fact, this sort of casual branch management imposes a cost borne by
| ordinary users (who find libraries randomly don't work with the version
| of ruby they happen to have installed) and average library developers
| (who can't be sure that they are targetting more than a single
| point-version, and end up fielding more support requests).

For me, this means that I a) have to advise prospective and current
clients to use Ruby 1.8.6, and b) need to cover my backside in regard to
security somehow. Fortunately, I can handle quite a bit of that myself,
and Ruby's patchlevel is reliable in my experience.

Maybe it'd be a good idea to advertise branch management on ruby-lang.org?

Together with some guidelines, that'd be a boon to people like me, I'm sure.

In the end, though, I have a bit of a harder time selling my Ruby
services, and using Ruby in my spare time to hack on projects for the
fun of it. Until now, I was lucky, and could pretty much dictate the
Ruby version that is in use. But I expect that to change, sooner or
later. Can't be lucky all the time.

As it is, I'll have to take a backseat, and only use other people's
libraries or frameworks when working with Ruby.

I can't spend my time testing against n versions, and working on fixes
to code (if I were developing on Ruby, and testing against 1.8 that'd be
a hassle already, adding tests and fixes against 1.8.x, too, increases
my workload considerably. Workload that I'm not productive).

One decision for me was, using JRuby 1.1 / JRuby 1.0.x. Which,
incidentally, provides the sort of release management I needs as a user. :|

(I know the differences between releases that I can expect, and can plan
accordingly. I don't need to rely on test breaking in interesting ways.
Hasn't happened yet, but still..)


- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

Yuppie Wannabes:
~ An X Generation subgroup that believes the myth of a yuppie
life-style being both satisfying and viable. Tend to be highly in
debt, involved in some form of substance abuse, and show a willingness
to talk about Armageddon after three drinks.
~ -- Douglas Coupland, Generation X
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgLqJMACgkQbtAgaoJTgL8HkgCfdgCNS3xImiekKjcSOAyxWNLl
c4MAnjJYaFWiPrHt9lg6t+KIcHBesyz5
=HQnZ
-----END PGP SIGNATURE-----

 

[Charles Oliver Nutter]

One decision for me was, using JRuby 1.1 / JRuby 1.0.x. Which,
incidentally, provides the sort of release management I needs as a user. :|

(I know the differences between releases that I can expect, and can plan
accordingly. I don't need to rely on test breaking in interesting ways.
Hasn't happened yet, but still..)

Interestingly, several of the failures in Ruby 1.8.7 were found by JRuby
developers. We tried to make several of the changes in JRuby and they
broke tests and Rails itself. JRuby developers should not be finding and
reporting bugs in Ruby releases.

The Ruby core team should consider instituting more stringent
regression-testing policies.

- Charlie