[Rubygems-developers] 0.4.0 bugfix release

[Jim Weirich]

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.

-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)