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

[Mauricio Fernández]

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.

How to make sure this won't happen? IMHO by documenting the policy and
making sure most people making gems follow it.

> require_gem 'log4r', "> 1.0.5", "< 3"
                                  ^^^^^
This is not realistic a priori, if the gem is done *before* log4r 2.0
is released. How could you know that a version to be released in the
future will have a compatible API?

> (Kind of crossing my fingers and hoping we don't get into a whole
> version globbing language....)

The actual 'language' ;) used to specify the version is not as important
as the policy issue.

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

This is a scsi driver, scraes the shit out of me, therefore I tapdanced
and wrote a unix clone around it (C) by linus
	-- Somewhere in the kernel tree