[Rubygems-developers] Another plug for Simon's patch

David A. Black dblack at wobblini.net
Thu Apr 1 03:33:42 EST 2004


Hi --

On Thu, 1 Apr 2004, Mauricio Fernández wrote:

> On Wed, Mar 31, 2004 at 05:49:32PM -0800, David A. Black wrote:
> > > Yeah, it's good.  You should be able to provide multiple version
> > > requirements, like
> > > 
> > >   require_gem 'log4r', '1.*', '> 1.0.5'
> > > 
> > > That much seems reasonable.  Now, stretching it a bit, what if version 1
> > > OR 2 or log4r was OK, but not 3?
> > > 
> > >   require_gem 'log4r', '[12].*', '> 1.0.5'
> 
> '1.*' is nice but it *still requires* a versioning policy.
> Imagine devel. A packages a gem with a dependency on 'foo', "1.*', at
> the time 1.0 is out. The developer of foo releases a newer,
> incompatible version 1.1. He's defeated the attempts of A to isolate
> his gem from changes in foo's API.

The same thing is true if > 1.0.5 means < 2.0.  It still doesn't mean
< 1.1.  I think trying to impose a versioning policy, in the sense of
telling people which digits have to flip or not flip under what
circumstances, is about as likely to succeed as telling people they
can only create a gem if they use Emacs.  

One way or another, some of this is bound to happen in real time, and
interactively -- that is, whoever is installing a gem has to be
notified if something is incompatible (which means the gem developer
has to flag that somehow) or breaks a dependency.  This prospect comes
naturally to me, since I *want* to know what's being installed (there
are some things, even on RAA, that I literally don't want on my
system), so I may not be the best at putting my head inside the
automatic dependency fetching scenario.


David

-- 
David A. Black
dblack at wobblini.net



More information about the Rubygems-developers mailing list