VERSIONS.txt
  CalendarX 0.6.6(stable)  January 03 2006
  (last modified for CalendarX 0.4.0)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)


Starting with CalendarX v0.1.8(stable), we are implementing a new four part 
version number system that we think you'll find sensible and easy to 
understand.  It offers several advantages over other systems for small to 
medium scale software projcts.  Here's how it works.

CalendarX version numbering scheme with four parts: V.B.F(C)

Version . Branch . Fix (Comment) 

Definitions:
  Version: significant code base difference from other major Versions
  Branch: new features beyond other branches (aka minor version)
  Fix: very little new functionality, mostly bug fixes
  Comment: added at the end to tell the user something about stability
    (exp)    - experimental release, definitely needs work, but it obviously
               has some functionality or it wouldn't have been released.
    (dev)    - development release, some bugs, but in a working state.
               Expect changes and new functionality to appear under (dev).
    (alpha)  - seems stable with NO identified critical bugs, requires more 
               testing and bugfixes.  Very minor new functionality, if any.
    (beta)   - candidate for stable release.  Beta is mostly for bugfixes and 
               minor feature adjustments, with essentially no API changes.
    (rcX)    - where X is a number (1, 2, etc.) Release candidate for a stable
               release.  No changes other than bug fixes.
    (stable) - well tested, serving in production capacity. additional stable
               releases in any branch will only be made for bugfixes.
  Critical bug: A bug that absolutely must be fixed before declaring a 
    branch to be in a stable form.
  Minor bug: Bugs that aren't critical.  Minor bugs are optional to fix before
    declaring a branch to be stable.

For example, the first stable release of CalendarX was that 0.1.8(stable) code
on June 13, 2004.  It represents the "0" Version (aka Trunk) of the code, and 
the "1" Branch of that code.  It went through several Fix stages (actually 
more than a dozen under the old version numbering system), and has been 
declared Stable as of this release: v0.1.8(stable).  

Once a branch reaches stable, it is very unlikely to have any further 
development of that branch of the code.  Once a branch reaches a stable state, 
the only future releases along that branch will be bugfix releases.

Any new features added to the code, other than very minor cosmetic changes, 
should cause the opening of a new code branch.  Several code branches may be 
active at one time, but should always specify in the HISTORY file what stable 
code branch it was started from.  

The major advantage of this approach is that fantastic new features
need not be held hostage to other, more difficult feature developments.  

Example 1: A particularly nasty coding problem is holding up development of 
  the 1.2.x(dev) branch, but a desirable new feature of that branch has been 
  completed, then it is entirely possible (and *desirable*) to release a 1.3 
  branch that builds on the stable 1.1 code base, but releases the desirable 
  new feature into the community without delay.  The 1.2 branch continues, or 
  it may jump ahead to 1.4 if other new features get added in.

Example 2: Some great new features added into the 0.9.x(dev) branch are very 
  desirable for 0.8.x(stable) users.  If these new features can be readily 
  backported into the 0.8.x(stable) code base, then a new branch called 
  0.10.0(dev) should be started to include those features.  This branch can 
  very rapidly be advanced to 0.10.x(stable) status because of the stability of  
  the 0.8.x branch code base and the small number of changes made.  Thus new 
  functionality can be released in a stable form without undo reliance on 
  CVS branches or other project managerial magic.  

Also, there is no upper limit on any of the numbers, so eventually 
one might reach v3.63.7(stable) or something like that.  It is unlikely to 
reach high numbers in the Fix part of the version number 
[i.e., v3.63.119(stable)] unless there were ridiculous difficulties in 
squashing bugs in that branch.

I think this numbering system, although truly insignificant (it is just a 
convention, after all), will help us produce a more reliable product more 
quickly.  Perhaps more importantly, it will definitely help us adhere to a 
philosophy of "Release Early, Release Often."

+lupa+
CalendarX.org