[Rubygems-developers] 0.4.0 bugfix release

[Mauricio Fernández]

On Mon, May 31, 2004 at 08:53:16AM -0400, Chad Fowler wrote:
> * some kind of versioning change (mauricio, eivind, or jim's idea(s))  
> should go into 0.5 for feedback/testing

So far, 3 versioning schemes have been proposed,
see http://rubyforge.org/pipermail/rubygems-developers/2004-April/000294.html 
for the details:

(1) format A: single version number, bumped on API extensions/changes.
  pros: simple to explain, trivially implemented
  cons: the number will increase *very* quickly; this scheme is stricter than 
        needed in the case of API extensions

Jim's 1.*.* is a variant of this (different notation, same basis), as
explained in 
 http://rubyforge.org/pipermail/rubygems-developers/2004-April/000432.html

(2) format B: x.y.z, where x is bumped on API changes, y on API
            extensions, z can be used for patchlevel/etc.
  pros: 
   * it is essentially complete, unlike the two variants of A;
     specifically, it is more expressive regarding API extensions
	 (consider v18 -- v19 in (A), 2.4.0 -- 2.5.0 in (B))
   * the major version number doesn't increase nearly as quickly as in A
   * this convention is fairly common
  cons:
   * more complex

a patch enforcing a versioning policy based on this format was posted in 
http://rubyforge.org/pipermail/rubygems-developers/2004-April/000296.html

(3) no scheme


As a somewhat separate issue, it was proposed that the API version number
be specified separately from the "main" version number; this way upstream
developers can use any scheme they want, and the API versioning policy
is only used internally by Rubygems.


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

Dijkstra probably hates me.
	-- Linus Torvalds, in kernel/sched.c