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

I'm using Gmail because the mail server I have been using is down right now...

On Wed, Feb 11, 2009 at 10:33 AM, Evan Phoenix <[e-mail]> wrote:
>
> On Feb 10, 2009, at 11:44 AM, Akinori MUSHA wrote:
>
>> At Tue, 10 Feb 2009 22:32:19 +0900,
>> David A. Black wrote:
>>>
>>> The problem is, though, that if a customer says, "We will only run
>>> 1.8", it usually either means 1.8.6, or else it means "We don't trust
>>> 1.9". I can't help thinking that the big thing is to get people to
>>> trust 1.9, and to smooth out any remaining problems with 1.9. Right
>>> now, it may be that the 1.8 "brand" has more trust, but that's just a
>>> coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
>>> 2.0, there would not be the same branding effect. (I know that's just
>>> speculation, but I do think that 1.8.x is having to play an awfully
>>> large number of roles.)
>>
>> Agreed.  Maybe it's time to (re)define the versioning scheme.  As I
>> said in another mail, I always feel twisted when the second version
>> number is called "minor".  What is more, even sharing the first two
>> numbers did not always mean API compatible before 1.8.6.
>
> I would hope that some consideration is given to how people expect version
> numbers to work. As you stated before, you've been thinking about ruby's
> versions like epoch.major.minor, but I'd expect that no one else has been.

OK, you are talking about the teeny part under some impression I'm yet
to follow.

In my point of view:

MAJOR(1) - means not much.  It is bumped when Matz really feels like it.
MINOR(8) - means backward compatibility.  It is bumped when backward
incompatiblity of a significant kind is introduced.
TEENY(7) - means a release sequence in a MINOR version series.

> This causes massive confusion and doubt about ruby. When a user upgrades to
> 1.8.7 and a significant amount of code begins to fail, they worry. When the

A significant amount?  I would really like to know more about it.
What we have done through the 1.8.7 development was essentially just
backports from 1.9 that don't change existing behaviors.

There are some cases where a library treads on an incompatibility land
mine, but they are mostly corner cases.  For instance, Rails 1.2 began
to fail after 1.8.7, but such libraries as ActiveSupport's core
extensions naturally need an update after a new version of Ruby is
released, because they tweak the builtin features (the language core)
deep inside.  No criticism or blame intended, but I simply wonder why
a simple fix for that problem was not shared soon.

The famous method clash with String#chars could have been easily coped
with in the Rails/ActiveSupport world just by adding "class String;
remove_method :chars; end" to disable the newly backported method.
(Technically, ActiveSupport's core extensions add methods not by
directly defining them in a class but by including a module -- that's
why the builtin method is called when ActiveSupport has one with the
same name)

Actually I received a mail regarding the problem from the author who
implemented the conflicting method/library, I replied with some
suggestions to solve the problem but got no reply, so I just gave up.
Next time I will proactively proceed with that.

> upgrade to 1.8.8 and discover they've been using new syntax that their
> coworkers don't have, they get worried.

True, only if backward incompatilitity that a step upgrade brings is
on an untolerable level for business use. (I hope not)

> They get worried because when they see a change in the 3rd number, they
> don't expect "this release breaks backward compatibility in major ways."

As I keep saying, I don't think there was that major incompatibility
introduced in 1.8.7 that affect ordinary people.

> In my opinion, we're doing everyone a dis-service by calling YARV and the
> trunk 1.9. It's such a huge rewrite, it clearly should be at the very least
> 2.0. If we did that, people would
>  1) Be quite happy there was a new ruby major release, as there as never
> been one.
>  2) Be very aware that it changes a lot, and it's not a simple thing to
> upgrade

It would be quite nice if requiring a huge rewrite is what everyone
welcome, but I'm not sure with that thinking of myself and people
around.

> The problems with the current situation are compounded by the fact that
> trunk is currently called 1.9.1, which indicates it's a minor change from
> 1.9, which is completely false.

People should learn that a .0 release is normally considered as a
developer preview, especially when so officially announced.  As for
Ruby, a new series has never stabilized with both feature and runtime
stabilities until a .3 release rolls out.

-- 
Akinori MUSHA / http://akinori.org/