From: Gavin Sinclair <gsinclair@...>
Date: 2004-07-12T07:54:02+09:00
Subject: Re: Business application building with Ruby

On Monday, July 12, 2004, 2:23:22 AM, James wrote:

> Gavin Sinclair wrote:

>>>Then how about using dates as versions?  Call the release made tomorrow
>>>20040712.
>> 
>> 
>>>That won't drive off users who are going to make the reasonable assumption
>>>that anything below 1.1 can't be trusted for real work, it'll let you
>>>distinguish one release from another, and everyone wins.
>> 
>> 
>> It's not a reasonable assumption.  The points made against that
>> assumption by various people carry more logic than your mere
>> assertion.
>> 
>> Using dates betrays any notion of a planned release schedule, so it's
>> not a win-win situation.

> Two apps, both at version x.y.z, may be in very different states of 
> reliability and feature creep.

> But for any given release if you are using Foo 0.2.0, and see  that 
> version 0.2.1 is out, it should mean something different than if 0.3.0
> comes out.

> Dates do not allow one to indicate if a release is major or minor.

> The version numbers of a given app should at least serve as some sort of
> code/feature "distance" marker, though the meaning will vary among 
> applications.

> If there is any sort of consensus among Rubyists on release number 
> guidelines then perhaps some kind soul may offer to write them up and
> put them on rubygarden.

Since RubyGems is concerned with version numbers, Jim Weirich has
written a RationalVersioningPolicy on the RubyGems wiki at
http://rubygems.rubyforge.org.

According to that policy, every time a backwards-incompatibile API
change occurs, the major version number gets bumped.  I guess there's
an implicit caveat for very early versions of a project, otherwise
we'd have version numbers like 15.0.1 frequently.  Jim?

Cheers,
Gavin