[Rubygems-developers] 0.4.0 bugfix release

Chad Fowler chad at chadfowler.com
Mon May 31 16:17:45 EDT 2004

On 31/5/2004, at 12:26 PM, Jim Weirich wrote:

> Chad Fowler wrote:
>> * some kind of versioning change (mauricio, eivind, or jim's idea(s)) 
>>  should go into 0.5 for feedback/testing
> Here is my thoughts on versioning.
> I like the major/minor/build numbering scheme where
> * build changes with any implementation change
> * minor changes with any backward compatible API change
> * major changes with any non-compatible API change.
> This scheme takes the best advantage of the versioned gem_require 
> statement and allows clients the most flexibility when using new 
> libraries.
> I think this policy should be formalized, documented and promoted as 
> *the* way to do versioning in Gems.  I don't think the policy should 
> be _enforced_.  In fact, I don't know of any way the policy could be 
> enforced (what would we do? black list non-compliant gems?  not 
> likely!).  I think this is a quality of implementation issue and 
> packages that consistently violate the policy will receive enough 
> negative feedback from users to bring them in line (and if they don't, 
> then its not that big of deal anyways).
> Another issue is what I call the pessimistic vs optimistic view of 
> require_gem package, ">= 1.2".  The pessimistic view says that version 
> 2.0 will (at least in some way) be incompatible with code written to 
> the 1.2 standard and therefore should not satisfy the requirement.
> The optimistic view is that, yes, version "2.0" is in some ways 
> incompatible, but we don't know for sure that it won't work.  So 
> perhaps 2.0 is ok.  Besides, saying that "2.0" does not fulfill the 
> ">= 1.2" requirement is rather non-intuitive given the standard 
> mathematical definition of ">" (greater than).
> Currently, the version requirements implement the optimistic 
> viewpoint.  The pessimists could be supported with ...
>    require_gem package, ">= 1.2", "< 2.0"
> But currently we don't support multiple requirements.  Furthermore, 
> this requires the pessimist to specify a range of acceptable versions, 
> which in truth is awkward.
> We could support the pessimists view with a new operator that didn't 
> bring along semantic overtones (as does ">").  I've played with 
> several, but the current option I kinda like is ...
>    require_gem package, "*> 1.2"
> This implements the pessimistic "greater than or equal to 1.2 and less 
> than 2.0" option and should satisfy those who wish to use it.
> So, I'm proposing two changes ...
> (A) implement multiple requirements, e.g.
>         require_gem package, ">= 1.2", "< 2.0"
> All requirements must be true for a package to satisfy the require.
> (B) Implement a pessimistic greater-than version operator.  
> Suggestions for the operator include "*>", ">>", "<*>"
> I think both (A) and (B) are useful.  (A) is more general and includes 
> the (B) case, but I think you still want (B) from a convenience 
> standpoint.
> I have a private implementation of (B) already working and I have 
> started on (A).  I can commit these if there is general approval on 
> this list.
> -

I strongly approve of (A) and mostly approve with (B).  My only minor 
objection is that the symbols for the operators don't look intuitive to 
me.  But, I can't think of a better idea.  I would be in favor of 
releasing both in the next RubyGems release and seeing what the 
community thinks.  My guess is that both would be used infrequently and 
that (A) would be used more than (B), but that's not a reason not to 
include them.

So, my vote is to commit.


More information about the Rubygems-developers mailing list