From: Akinori MUSHA Date: 2009-02-11T03:54:32+09:00 Subject: [ruby-core:21959] Re: New hash : syntax for the 1.8 series? --pgp-sign-Multipart_Wed_Feb_11_03:55:44_2009-1 Content-Type: text/plain; charset=US-ASCII At Tue, 10 Feb 2009 22:30:48 +0900, Eero Saynatkari wrote: > I personally feel this is not the best course of action. I see no > reason for anyone to stay with the 1.8 line unless it is due to > some company policy/security/risk concern, and in those cases the > only changes should be security and bugfixes that do not change > the language. We provide ruby_1_8_6 and ruby_1_8_7 branches (patch releases) for that very purpose. What I feel was unfortunate with hindsight is that the development of 1.9 lacked speed and main features until YARV and M17N actually worked hard on and finally took place. When many core developers started to expect a 1.9 release, the 1.8 series had already reached 1.8.5 without getting much backport because nothing in 1.9 had been (at least seemed) fixed and promised. The early 1.8 series also had problems with backward compatibility. Partly because it had many bugs and misfeatures gradually found and exposed, and mostly because there were no development policy, incompatible changes had often been made. So I took over the maintainership, worked out a policy, and released 1.8.6. I had to start backporting after that. The backports made in 1.8.7 might surprise many people, but from my point of view they should have been done long time ago. > That is, I do not understand the case for essentially two parallel > lines of implementation of new features. So far as I understand, > there is nothing in 1.9 that would disqualify it from use if one > accepts the changes anyway. Migration is certainly always something > that takes a certain amount of time, but 1.8 -> 1.9 is not too bad > just to get working--after which one can start using new features. > My feeling is that this migration is best get over with as soon > as possible. There are many kinds of users and many situations. Some people agrees with me that consciously or unconsciously, you tend to avoid using new features if you still have some install base of old versions of ruby. The funny thing is, that's still the case even for a new feature you proposed or implemented. One day, after you migrated to a new version of ruby, you find yourself thinking of proposing a new feature completely forgetting that you once proposed something similar, which has been adopted in the new version. How did we get used to that? My answer is lack of timely backports. Let's think about minor new features. Imagine you had code for 1.8, and you knew you could slightly improve the code by using some minor new features in 1.9. Would you take a risk and rewrite the code? I think small enhancements should be introduced bit by bit in a daily manner and not a bunch at once in every three year, considering that a new feature in Ruby often introduces user to a good, beautiful style of coding. Ruby developers deserve a mickle of fun and convenience made by every a little new feature introduced everyday. > I am also not entirely convinced about the "not maintaining two > versions of the library" argument, in that if the 1.8 line is > essentially hard frozen for new features, then there is no need > to do *anything* to create an 1.8 branch but to keep what one > has right now (and any updates to 1.8.8 will not break it, just > fix bugs etc.) On the other hand, it would seem to me that if > 1.8.8 is unlike 1.8.{6,7} but also not quite like 1.9, there > would be a need to actually manage the two library branches > because there is variance in both. Given the following points, it seems to me that you can drop support for old "teeny" releases of ruby in a new version of your library after a certain period of time. - 1.8.8 will be upper (mostly) compatible with 1.8.{6,7}. - One who needs to stay at 1.8.{6,7} would not want a new version of your library with new features either. Of course every developer has their own maintenance policy that should be respected, but I would suggest the way of thinking as the ruby 1.8 maintainer. > As usual, I am keenly aware that I may be overlooking something > crucial, and would be happy to hear where my thinking has gone > wrong. The most crucial point I must not overlook is that the cost of every step upgrade from 1.8.x to 1.8.(x+1) must be minimized. I will keep that ceintainly in mind. > Also, thanks for both maintainers' hard work.. it is often > thankless enough without people like me complaining on top > of that. Never mind. Thank you for your feedback! -- Akinori MUSHA / http://akinori.org/ --pgp-sign-Multipart_Wed_Feb_11_03:55:44_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkmRzbAACgkQkgvvx5/Z4e5qAACgkzoCKEjNb4enw4uj9CLFWuLV hvYAoKXzjbBZE2+uz+Eyzhwqi0cuTj/I =Bazd -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Feb_11_03:55:44_2009-1--