Re: Simpler version naming

On Fri, 18 Feb 2005 16:24:05 -0500, Greg Beaver <greg@chiaraquartet.net> wrote: > 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" Well, I was saying to use that here and then make the specific statements later. Your replacement is much better, though. > > > [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. > I would say this is a better solution. It's much less confusing and won't lead to duplicate package versions in Foo, Foo2, and Foo3. However, I can still see problems with people who simply want to do a full re-write. If you have a bunch of releases before Foo2 goes stable you could have Foo2 2.0.0a35. In addition, this makes it impossible to tell what has changed. Allowing the 0.x.y for pre-stable releases allows for at least some x and y changes to denote bug fixes or additions / changes. -- Justin Patrin