--pgp-sign-Multipart_Thu_Apr_17_05:48:00_2008-1 Content-Type: text/plain; charset=US-ASCII Hi, At Thu, 17 Apr 2008 00:09:58 +0900, Florian Gilcher wrote: > 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 :) I may digress, but Ruby 1.9 is far more than just VM. There are so many fancy things we regret being unable to backport. > 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. It all depends on your standpoint, really. If you are a mission critical production application developer, you would just want bug fixes and nothing else. If you are an average production application developer, performance improvement would also be welcome. If you are a library developer, the bigger the difference between 1.8 and 1.9 the more difficult it is to develop and maintain your library. If you drop support for 1.8, you are leaving average users behind. If you stick with 1.8 and hesitate to support 1.9 until it is production ready, you are left behind when 1.9 is ready. So changes that makes 1.8 closer to 1.9 may help you. If you are a bleeding edge developer, you couldn't care less about 1.8 as you say. But after all above, if you are a Ruby developer like me, you must care about all kinds of people using Ruby in various ways. I'll tell my thoughts in detail below. > 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. You could think about forward compatibility between 1.8 and 1.9 as well. To encourage users to stop using a feature in 1.8 that are deprecated in 1.9, it is sometimes an optimal solution to backport the new method to 1.8. Generally the newer version is (re)designed based on better methods, styles and techniques, so it is often a good idea to make people get used to them through backports, rather than asking them to make big changes after a long time has passed. > 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? It doesn't make much sense to me. Why would users who stick to older releases of Ruby suddenly decide to introduce a new library, or use new features when writing one? You probably know but there are the Ruby 1.8.X-pX series for the last two releases for those who don't want changes but just bug fixes. Considering 1.8.5 was a bug fix release of 1.8.4, it has been maintained for more than 2 years. Even if the 1.8.5 maintenance were to be dropped, you could then move to a newer release without much difficulty, because backward compatibility is kept pretty well and a few exceptions are documented. > I also believe that the invested time in backporting is better > invested to improve ruby1.9. Backporting a radical development branch to a stable branch is like making steps for gradual migration instead of giant leap migration, which often demands you a complete rewrite of a big part of your code. If you froze a branch soon after the first or maybe second release from the branch, what would happen? As the difference between ruby branches gets bigger and bigger, every library author would: a) Have to maintain one branch for each ruby branch, b) Write and maintain bridge code on his/her own, Or: c) Feel conservative about using new features aggressively, and the new features would not get used as hard as they deserve. What we have been doing in the 1.8 development is eliminating each developer's duplicated effort of a) and b) to avoid the worst case, c). If people did not use or even know about new features for a long time, the development branch would eventually be full of experimental, untested features. Decent tests would not be performed widely until after several years of aggressive development, while the stable series solely enjoys its heyday without any changes. Then one day, when the first release from the development branch is about to release, you will be told: "OK, the new version of ruby is getting ready. Before we release it, we would like you folks to test these 1000 new features with your applications and libraries. Beware, you'll have to fix your code around before running it with the new version if you are using any of those 100 features that have incompatibilities with the previous series". It is not my imagination. Similar things actually happened a few times before, albeit the figures above are a bit exaggerated. Every time that happened the average user got confused by and complained about the incompatibilities and unknown new features suddenly introduced when a new major version was released. That caused the new version to take much longer time than expected to become stable and get widely used. We used to lose users because of all that. > I support and like Rubys bazaar-style development, but a bazaar begins > to fall apart when huts change their position every other day. As I said above, we have been improving the development scheme to offer reasonable options for various kinds of users and scenes. I can say we have been and will always be consistent with that. > 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. I agree. Sooner or later we will have to make a switch, but I don't think we are ready to go for that. For 1.8 and 1.9, it's so late it doesn't pay. Maybe from 2.0? It's matz's call though. -- Akinori MUSHA / http://akinori.org/ --pgp-sign-Multipart_Thu_Apr_17_05:48:00_2008-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgGZgAACgkQkgvvx5/Z4e7MlgCgp1n1GgJ6xpNpZDKzSwdebzF8 tiQAoIDIxQNHkgi54dKXviV46xRP4Sv+ ¥·6 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Apr_17_05:48:00_2008-1--