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