[Rubygems-developers] Another plug for Simon's patch
batsman.geo at yahoo.com
Thu Apr 1 10:15:51 EST 2004
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', '.*', '> 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
More information about the Rubygems-developers