Simpler version naming

Hi, Here is an attempt at consolidating package naming and version naming scheme: All versions must be x.y.z[postfix] as in 0.2.3, 1.0.0, 2.5.3 or 1.3.0al Each digit of the version implies a change of lesser significance. In x.y.z, x is used to denote the API version, y is used to denote the feature set, and z is used to denote any minor bug fix revisions. Versions with x = 0 must be devel, alpha, or beta stability. All stable packages must have x = 1. When a package reaches stability, at least one release candidate must be released of format 1.0.0RC* where * is the release candidate number (as in 1.0.0RC1, 1.0.0RC2). Alpha and beta releases of version 1.0.0 should be numbered using 0.y.z until release candidates. The first stable version must be 1.0.0. If there are any bugfix releases, z must be incremented. If there are new features added or significant changes are made to fix a bug, y must be incremented. If a package changes its API, or breaks backwards compatibility in other ways, then x must be incremented, and a new package must be released. The new package must postfix the package name with either the value of x or _vx, as in Foo2 or Foo_v2. The first release of such a package must not be stable, and should be either 0.y.z for alpha/beta releases, or a release candidate 2.0.0RC*, following the same rules as 1.0.0RC*. bugfix releases must retain the stability of the last release. Version 1.3.3 (stable) cannot be upgraded to version 1.3.4 (beta). If a major change is made, requiring a drop to beta for testing, use 1.4.0a1 (alpha), 1.4.0b1 (beta) or 1.4.0RC1 (beta) instead, and following the RC naming rules. Here is a minimal life cycle of package Foo: Foo version 1.0.0RC1 (beta) [initial package] Foo version 1.0.0 (stable) [same code, no bugs were found] Foo version 1.1.0 (stable) [new features added] Foo version 1.1.1 (stable) [bug fixed] Foo2 version 2.0.0RC1 (beta) [API changed] Foo2 version 2.0.0 (stable) Here is an extended, and more typical life cycle of package Bar: Bar version 0.1.0 (alpha) [initial package, feature set is not complete] Bar version 0.2.0 (alpha) [new features added] Bar version 0.2.1 (alpha) [minor change, bug fixed in existing feature] Bar version 0.3.0 (alpha) [new features added] Bar version 0.4.0 (beta) [bugs fixed, API is complete] Bar version 0.4.1 (beta) [bugs fixed] Bar version 1.0.0RC1 (beta) [bugs fixed, package is considered stable, prepare for stable release] Bar version 1.0.0RC2 (beta) [more bugs fixed] Bar version 1.0.0 (stable) [no new bugs found after RC2, release first stable version] Bar version 1.0.1 (stable) [minor bug fixed] Bar version 1.1.0 (stable) [new feature added] Bar version 1.1.1 (stable) [minor bug fixed] Bar version 1.1.2 (stable) [minor bug fixed] Bar version 1.2.0a1 (alpha) [major new feature added, drop to alpha until API is solidified] Bar version 1.2.0a2 (alpha) [bug fixed, API changed slightly] Bar version 1.2.0b1 (beta) [API solidified, bugs fixed] Bar version 1.2.0RC1 (beta) [all known bugs fixed, API solid] Bar version 1.2.0 (stable) [no new bugs found, release stable] Bar2 version 0.1.0 (alpha) [change API dramatically, start a new package, take advantage of new PHP 6 features] Bar2 version 0.2.0 (alpha) [add in new features, fix bugs] Bar2 version 2.0.0RC1 (beta) [prepare for next stable release] Bar2 version 2.0.0RC2 (beta) [fix bugs] Bar2 versoin 2.0.0 (stable) [no changes from RC2]