[ruby-core:21959] Re: New hash : syntax for the 1.8 series?

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/