Re: Simpler version naming

Justin Patrin wrote:

On Fri, 18 Feb 2005 15:59:46 -0500, Greg Beaver <cellog@php.net> wrote:

Hi, Here is an attempt at consolidating package naming and version naming scheme:

Thanks, this is long overdue.

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.

Here's the same problem again. Did you perhaps mean "All stable packages muct have x >= 1."? No, that is too vague. Better is "All stable packages with API version 1 must have x=1. When the API version changes, the package name must append the new API version number and increment x"

[sneeep]

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*.

How about chaning that last line to: "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 x.0.0RC*, as in 2.0.0RC1, following the same rules as 1.0.0RC*." and adding: "The first stable release of Foo_vx or Foox must be x.0.0, such as Foo2 2.0.0." I actually now think the solution I outlined in my reply to Pierre is better than the existing RFC. It will result in 2.0.0a5, 2.0.0b4, and so on, but it will be simpler and clearer.

Basically, this would be typical scheme with the new solution, starting from 1.0.0: 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 2.0.0a1 (alpha) [change API dramatically, start a new package, take advantage of new PHP 6 features] Bar2 version 2.0.0a2 (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] This way, there is no sudden inconsistency between 1.2.0 and 2.0.0. After all, decreasing a version number is bound to cause confusion. "Now was that Bar version 0.3.0 or Bar2 version 0.3.0?" If this looks good, I'll translate it into prose. Greg