--nextPart2251829.cxrcRHvp1j
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I didn't see a CC in the email Matz sent me, so I'm forwarding it on to the=
=20
group.

The context is that I'm contemplating some optimizations to REXML that will=
,=20
by necessity, cause some API changes which will break some code using REXML=
=2E =20
I emailed Matz and asked for his opinion on how to proceed, and asking him=
=20
whether he wanted to discuss it in private, or in Core.  He responded that=
=20
he'd like to see it in Core, so here is his response to my email.  My=20
response to him is after the forwarded part.

=2D---------  Forwarded Message  ----------

Subject: Re: Question about massive API changes
Date: Friday 27 January 2006 22:35
=46rom: Yukihiro Matsumoto <matz / ruby-lang.org>
To: "Sean E. Russell" <ser / germane-software.com>

Hi,

On 1/27/06, Sean E. Russell <ser / germane-software.com> wrote:
> Hello Matz,
>
> If you think this is better discussed in core, let me know, and I'll repo=
st
> it there.

Let us discuss there.  I'd like to hear opinions from others.

> As I see it, I have three options:
>
> 0) Warn everybody, make the changes in 1.9, and have Ruby 2.0 break a lot
> of applications that use REXML.  This will Piss People Off (tm).
>
> 1) Create a new package.  REXML2, or something, and add it to the tree. =
=20
> This is, basically, a fork. People can migrate their apps to the new API =
as
> they see fit.  This would mean:
>         a) A duplicate REXML tree, which bloats the Ruby distribution,
>         b) A semi-duplicate tree, containing only the files which have
> changed and which references the base REXML installation.
>         c) Use a library versioning tool, like Thomas Sawyer's Roll
> (http://roll.rubyforge.org)
>
> 3) Don't do anything.  Which sucks, because it means no optimizations.

How about option 4, replace REXML in 1.9? This means no duplication in
the distribution (1.8 with old REXML, 1.9 with new REXML).  For
migration issues,
you can provide gems for each REXML that allows incompatible versions
 co-exist. Or, rename new version to, say, XML.

matz.

=2D------------------------------------------------------

I was actually going to suggest renaming the package to, simply, XML, but I=
'd=20
want to get approval for that level of egotistical renaming.  Of the=20
solutions that have occurred to me, this (2a or 2c) is the one I prefer,=20
although I don't particularly like any of them.  (2) bloats the Ruby=20
distribution, especially if it becomes SOP (Standard Operating Procedure, f=
or=20
the non-native-English speakers).  At some point, you *have* to clean out t=
he=20
cruft, so at some point, you're going to break old applications. =20

Personally, I think that breaking legacy code is the *worst* kind of breaka=
ge. =20
You'll have server apps that people installed ages ago running on servers=20
sitting in closets that have been walled over, that have for years quietly=
=20
been doing their jobs so well that people have forgetton that they existed,=
=20
except as an IP on the subnet.   And they suddenly stop working... and I=20
guarantee that it won't be obvious to most people what caused the breakage,=
=20
because the people doing the upgrades aren't the ones responsible for the=20
apps.  It will be an especially obscure problem for people who hired=20
contractors who secretly used Ruby for some part (or all) of an application=
,=20
and then left and moved to Albuquerque.  Some consultants actually *like*=20
this sort of thing: the phone rings, an old client in a panic, and dollar=20
signs dancing like proverbial sugar plums... but I would be embarrassed by=
=20
it.

There's a discussion about library versioning that this issue is skirting. =
 I=20
can solve my specific problem, but I think that, as Ruby ages, you'll see=20
more and more issues like this cropping up in popular libraries like YAML,=
=20
for example, and it would be worthwhile discussing a broader solution. =20

However, while I think the topic of library versioning is one that the Ruby=
=20
community should really be putting more effort into, I'm selfishly concerne=
d=20
about a specific solution about what to do with REXML.  I have code that=20
halves the current memory usage, but I can only do it by breaking some -- a=
nd=20
what might be common -- idioms.

In addition to Matz, I'd most particularly like to hear from the various Da=
ves=20
in the group.  I find that the Daves' opinions are often worth paying=20
attention to.  Any suggestions are greatly appreciated.

=2D-=20
=2D-- SER

"As democracy is perfected, the office of president represents,=20
more and more closely, the inner soul of the people.  On some=20
great and glorious day the plain folks of the land will reach=20
their heart's desire at last and the White House will be adorned=20
by a downright moron."        -  H.L. Mencken (1880 - 1956)

--nextPart2251829.cxrcRHvp1j
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux)

iD8DBQBD2vy8P0KxygnleI8RAieSAKCV1kj3FUCgcoVADxWh7RuldvLV3wCgpEaH
BXSb/S1kf3Fjqb2VpWlOjB8=
=+cGf
-----END PGP SIGNATURE-----

--nextPart2251829.cxrcRHvp1j--