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

Zitat von Greg Beaver <greg@chiaraquartet.net>: > > > 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. And could be solved by taking libxml as an example again. libxml2 started with version 2.0 iirc. But that also implies that no libxml 2.0 would be allowed. > >> 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. Why? If the developer feels like he wants to make a clear cut with his rewrite, let him so. It wouldn't break anything. The proposed changes want to make sure that no BC breaks happen within one package lifetime. That doesn't mean that you are not allowed to end a package's lifetime if you don't break BC. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft