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

Marshall Roch wrote:

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.

I agree.

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.

This is why I think complete rewrites with no BC break should not be major version increases - but Lukas and Pierre feel differently. I would propose that complete rewrites should be a minor version increase of at least 10, so that 1.2 becomes 1.12. In this way, we can have Foo 1.x and Foo2 2.x I really think major version increase probably should ONLY be for BC breakage, otherwise it's just a huge mess that cannot be automated. Acceptable? Greg