VERSIONS.txt
  CalendarX 0.9.0(dev)  January 06 2008
  (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

