[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>

Okay. I've got Ruby compiling. I'm attempting to get everything in

17 messages 2006/01/05
[#7058] Re: More on VC++ 2005 — nobuyoshi nakada <nobuyoshi.nakada@...> 2006/01/06

Hi,

[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)

Hi,

22 messages 2006/01/10
[#7097] Re: mathn: ugly warnings — Daniel Berger <Daniel.Berger@...> 2006/01/10

Hadmut Danisch wrote:

[#7098] Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/10

Daniel Berger wrote:

[#7118] Re: Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/12

*Dean Wampler *<deanwampler gmail.com> writes:

[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>

Hello,

23 messages 2006/01/28
[#7228] Re: Question about massive API changes — Caleb Tennis <caleb@...> 2006/01/28

>

Re: Question about massive API changes

From: Gavin Sinclair <gsinclair@...>
Date: 2006-01-28 06:21:08 UTC
List: ruby-core #7227
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


In This Thread