[#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: dblack@...
Date: 2006-01-28 17:17:37 UTC
List: ruby-core #7231
Hi --

On Sat, 28 Jan 2006, Gavin Sinclair wrote:

> 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.

Please not a '2' library.  There are already so many ruined names of
libraries and programs around -- names that were perfectly reasonable
until their version number got glued on, whereupon the sound like
names no one would ever have chosen for a program (what kind of name
is "bunzip2"?).


David

-- 
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming May 1, 2006!
http://www.manning.com/books/black

In This Thread