Re: [PEPr] Call for votes on RFC::VersionNaming

Alan Knowles wrote:

Alan Knowles (http://pear.php.net/user/alan_k) has initiated the call for votes on RFC::VersionNaming. Please review the proposal and give your vote here: http://pear.php.net/pepr/pepr-proposal-show.php?id=65

I think the proposal is great, but I have to quibble about one thing. Call me petty if you wish, but I dislike having second versions of packages with version numbers other than 2. Why? A package version is identified by three numbers: a.b.c. The way I read it, {a} is the package release. A profound rewrite or a large feature-leap of a package implies an increment of version number {a}. {b} is the API version of a package. Within the same release, whenever an API change is introduced, {b} is incremented. {c} is the bugfix release marker. Whenever a bugfix is released, {c} is incremented. Under this naming scheme, it'd be possible to have My_Package2 version 3.0.0 which is strange. If there is a difference justifying the change from 2.x.x to 3.x.x, then the package should become My_Package3, so that users can have version 2 and 3 coexist. In other words, the proposed naming scheme in fact defines a version name as three numbers: My_Package{y} a.b.c. What I'm asking is: What's the difference between {y} and {a}? Cheers, Sérgio