From: "Mauricio Fernández" <batsman.geo@...>
Date: 2004-11-18T08:02:31+09:00
Subject: Re: [ANN] rpa-base 0.2.3

On Thu, Nov 18, 2004 at 05:29:46AM +0900, Ryan Davis wrote:
> >>Surely having a package/program/library name and a
> >>version number as separate things is not only more aesthetically
> >  ==============
> >It's not primarily about the version number itself but about an API
> >declaration.
> >
> >Since the new RubyMail will have a completely incompatible API, it is
> >de facto another library -- and no longer the original "RubyMail", 
> >hence
> >the possible need for another name. RubyMail2 shows its heritage.
> 
> I disagree completely. Every time I extend a class or change the 
> semantics of a method I'm making an "incompatible API". 

Well maybe I'm drawing too many conclusions from the "*completely*
incompatible" expression (emphasis mine). I assumed it meant a radical
change, which makes the lib. so different that it could use a new name.
We would have to see the code or ask Matt Armstrong about the extent of
the changes.

> That is just  part of writing code. I'm not going to change the package name every 
> time I make an incompatible release. I'd be up to ZenWeb211 and 
> RubyInline39 by now. Despite all those incompatible releases, I haven't 
> gotten any complaints about my package names being misleading.

Note that I am not advocating for a library name change on every
incompatible release; that's something the usual x.y.z versioning scheme
aka "rational versioning policy" handles well:

http://rubygems.rubyforge.org/wiki/wiki.pl?RationalVersioningPolicy

That's a fairly exceptional measure taken in some precise situations;
RubyMail's case looked like one of them but we cannot be sure until Matt
clarifies that.

> Further, I put VERSION in all of my main modules / classes in order to 
> allow testing against to determine levels of compatibility.

That seems a good idea; it should probably belong into
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices or
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign

> The only reason I see really needing to change the package name is if 
> you wanted to have multiple versions installed at the same time and 
> usable potentially by the same morass of dependencies. 

Matt Armstrong talked about making RubyMail and the "new RubyMail"
(which I would consider packaging as rubymail1) coexist. By doing
the 'soname renaming', you make that easier for a number of systems,
and third party sw. dependent on RubyMail wouldn't need to be adapted
specifically for them.

-- 
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/