On 1/28/06, Sean E. Russell <ser / germane-software.com> wrote:
>
> > 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.
> > 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.


My instinct: new library "REXML2".  It's a hack of a version-migration
scheme, but it follows an established pattern, and the general problem
shouldn't be tackled now: it's too thorny.

Concern about bloat is insignificant.  Ruby should come with a decent
XML library, and that library should take advantage of worthwhile
optimizations as they become available.  For a bit of bandwidth and
disk space, who cares?

I think Matz's option 4 is too aggressive for the reasons Sean stated.

So a semi-duplicate tree gets my vote.

David^H^H^H^H^HGavin