Re: Core support for Gems, and namespace

On Wed, Jul 28, 2004 at 11:29:53AM +0900, Gavin Sinclair wrote:
> I don't want to ram library versioning down anyone's throat, but on
> the one hand, you say you don't like the fact that RubyGems bothers
> with versioning (it's overengineering, and you don't see a use for
> it), and on the other hand, you point out two very good reasons to
> have it: allowing apps/libraries to cope with changes to APIs in other
> libraries; and avoiding "CPAN upgrade hell".
> 
> Since there are two good reasons to tackle versioning, why not embrace
> it?

You are implying that the options are
 * tackling library versioning as done by RubyGems
 * not doing anything about it
However, RubyGems' way to solve that is not the only possible solution. 

RPA will be doing "full version sets", which means that all libs within
a RPA release will work well together. See the 2nd point in 
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ .
One will be able to have several RPA releases installed simultaneously.

Regarding Austin's example, diff-lcs-1.0.2 would replace diff-lcs-1.0.1
in the last RPA release, so nobody would install 1.0.1 anymore (they'd
get 1.0.2). diff-lcs-1.1.0 would be shipped with a later release.
End users/developers can choose between:
(1) committing to the API from a particular RPA release: at that point,
    you use all the libs *from that release*. No need to perform
    cherry-picking with a  require "foo/requirements".
(2) always using the lib from the latest available RPA release

(1) is done as follows:

require 'rpa'
RPA.version = "0.0"

and then just 
 require 'foo'
 require 'bar' 
as usual.  RPA.version = x  is effectively a declaration of the APIs
you're going to use.

Only one RPA.version = x  is needed per app, and contradicting 
 RPA.version = x  specifications are an error and reported as such.
Note that inside a rpafied lib/app, there's an implicit 
 RPA.version = the current version
so that a  require 'foo'   will take the foo from the same release.

(2) is done with

require 'foo'

This means that external (i.e. not managed by rpa-base) scripts need no
modification if the "use the latest RPA release" semantics are desired.
rpa-base does this without requiring ad-hoc mechanisms cause it is able
to install in all of $prefix, with the usual semantics (atomicity, strong
dep. management, revdep tracking, ability to upgrade/uninstall, etc)

(1) addresses both the API compatibility and the  "upgrade hell" issues,
because a developer could choose to add
  require 'rpa'
  RPA.version = "x.y"
to its app and know it is going to work forever. He would be able to
develop against newer RPA releases simultaneously, so he could keep
legacy apps which use older APIs and develop new stuff at a time.
He wouldn't be required to specify per-lib versions since the RPA team
would do that work for him (ensuring the APIs remain stable within a
RPA release and backporting bugfixes to older releases).

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com