From: Akinori MUSHA <knu@...>
Date: 2009-02-11T04:44:52+09:00
Subject: [ruby-core:21963] Re: New hash : syntax for the 1.8 series?

--pgp-sign-Multipart_Wed_Feb_11_04:45:59_2009-1
Content-Type: text/plain; charset=US-ASCII

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 admit I've always been skeptical of the gradual migration approach.
> I don't see how it plays out with actual code, and I've never talked
> to anyone who actually does it or wants to do it. I know a few people

In my view, every new piece of code you write or add is part of
migration, like avoiding upgrade-unsafe method, using a new method
that performs well, etc. .

> who have run 1.8.7 (I installed it to learn about it but don't use
> it), but by far the majority of opinions I've heard amount to: use
> 1.8.6, or make the move to 1.9.

That's not a surprise for me considering that 1.8.6 was the first
version that had decent continuous support by a decent maintainer
under a decent policy.  I'm proud of that, and proud of Shyouhei.

However, there are still bugs found in the 1.8 series and some of them
are difficult to fix in 1.8.6 due to its strict backward compatibility
policy or implementation defects.

I would suggest frameworks and libraries move at least to 1.8.7 soon.
Incompatible changes from 1.8.6 are minimal, and all user visible
changes are documented.  If any of you have any problem in upgrading,
please let me know.  Maybe I can give some clues.

Adopting 1.9 now for production is a brave move, but frameworks and
popular libraries should prepare for that as soon as possible.  While
at fixing version dependent parts, make good use of backports in 1.8.7
wherever appropriate to reduce code.

> Can you put lots of warnings in 1.8.8, so people will see that it's a
> bridge version? :-)

I have already added warnings to most of the methods that will
disappear or change in 1.9.  There is also a plan to introduce a
compatility warning framework.  I'm not sure as to how or when,
though.

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

--pgp-sign-Multipart_Wed_Feb_11_04:45:59_2009-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEABECAAYFAkmR2XcACgkQkgvvx5/Z4e6QQACcCYbI419BJXxm5joq6as31hwC
tDoAmwcn/v6lbCUsyjA+7HfqBCyTPkF2
=4flC
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Feb_11_04:45:59_2009-1--