Re: [RFC] BC breakage in PEAR - how to handle it properly

Greg Beaver wrote:

If a minor BC break occurs, or BC is maintained, but a package is completely re-written, a major version number should be incremented in package.xml, and current PEAR systems already in place should be used. The installer should be modified so that a <dep rel="ge" version="1.5"> will fail if the major version is > 1, unless another explicit <dep rel="lt" version="3.0"> is specified. If a major BC break occurs, then the package should be released as a new package as detailed below. [snip]

Package Foo version 1.x will be named "Foo" Package Foo version 2.x will be named "Foo2" Package Foo version 3.x will be named "Foo3" In addition to these naming conventions, the versioning for Foo2 shall start with major version 1.0

So would it be possible to have Foo 2.0 (complete rewrite, no BC break) and Foo2 1.0 (BC break)? That sounds really confusing.

Third, class naming conventions shall follow the directory structure as well, class Foo2, class Foo2_Supporting_FileOne.

If complete rewrites with no BC break ends up being Foo2 1.0, you'd have to modify all packages that depend on it from Foo to Foo2 (could be a lot of static calls in a lot of files) even though they should be able to use the new version anyway. -- Marshall Roch http://pear.php.net/user/mroch