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

I'm citing a message from talk, but I think it better fits into core:

On Apr 16, 2008, at 4:40 AM, Pena, Botp wrote:
> chuck-full, this looks like ruby1.9 without the vm :)

Thats pretty much why i'm not looking forward to the 1.8.7 release.

Ruby 1.8 is the major ruby version that is marked production-ready.  
While there are cases where changes are necessary, this should mean  
that the API is stable - at least when it comes to core classes, but  
to some extend, this should also be true for the standard library. The  
core should be frozen.

Those changes are not minor. While they are backwards-compatible, they  
severely break forward-compatibility between 1.8.6 and 1.8.7. While  
those changes are nice, it gets increasingly hard to track what  
features a specific minor(!) core(!!) version of Ruby  actually  
supports. As there are still many interpreter installations out there  
that are not even  on 1.8.6-level those features are essentially  
useless. For example, some Linux packaging tools do not even install  
1.8.6 (apt for example). If you target your code towards a minor  
version, you will  be in a world of pain. As developers often use the  
most recent version for development, chances are there that you run  
into that trap. You can multitest, but it artificially increases  
testing complexity. This is beginning to get a real problem when it  
comes to configuration management.
Also, as we do have multiple interpreters for the standard-1.8.6- 
distribution, it breaks compatibility for those.

There are cases where backporting would make sense (in edge cases  
where there is really only a brutal hack in use [e.g. #instance_exec,  
which does not seem to be backported]).  But in case of all those  
Enumerators:  If I use them, my code breaks on all older versions. So,  
any sane person keeps his hands off them. Where is the point in  
supporting them?

I also believe that the invested time in backporting is better  
invested to improve ruby1.9.

I support and like Rubys bazaar-style development, but a bazaar begins  
to fall apart when huts change their position every other day.

There are multiple solutions to this problem:
* freeze the core-api for major versions upon release candidates.
* freeze the core-api before developing a new release (python style).  
This might not fit the usual ruby development style but would make it  
easier for non-mri interpreter teams to develop some kind of standards  
ahead of an MRI release.
* provide a backport-library (or gem) that implements those features  
for all older  versions of a series (can be hard in some cases) that  
all developers of "edge"- libraries can depend on.
*  be sane about adding features inside a series. Ruby is rich on  
sugar, but you should not add sugar to a cake that is already  
finished. "Sane" is intentional: make a lax statement on what should  
and what should not be added in a minor version, without specifying  
hard rules. This means that a discussion is needed on whether those  
changes were "sane" or "not sane".

Also, this kind of release policy is known in the administrator world  
and it gets increasingly hard for me to get people to even consider  
ruby because of it's erratic nature when comes to the core.

Regards,
Florian Gilcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgGFq8ACgkQJA/zY0IIRZbqzwCeI1amP3v4P5d1/hMglc57q5S7
l00AoKPLXbgy4vZAuL2IfHATUQERb4Gb
=d/un
-----END PGP SIGNATURE-----