Re: BC breakage results

On 18 Sep 2003 at 22:45, Greg Beaver wrote: > We've reached what seems to be a typical position: lots of stuff has > been said, and no one is in favor of anything to solve the problems, > so business continues as usual :). > > Unresolved questions that need attention: > > 1) What should be done about minor BC breakage? > > - it is a bad idea to have Foo version 2.0 and Foo2 version 2.0, this > will only cause confusion - nobody likes any solution proposed. We > can't ignore this. > > 2) How much of an API change would be necessary to do a Package2 > release? > > ======= > > I am starting to believe that PEAR wants an impossibility: you can't > have BOTH BC and automatic upgrades without some kind of structure. > > The only solution that can solve the problem without the changes I've > proposed is to explicitly state that any packages with dependencies > must depend on the latest version of the package, or be considered to > be outdated and no longer viable. So, which is it folks? Solve the > problem by allowing older versions of packages to co-exist with their > newer versions, That's my preference. You can't assume that every package will be updated in just a few days when after a BC-break. Also you can't assume that everybody will move to 2.x (maybe in beta-mode) when the 1.x will at least still be supported. > or simply keep things as they are, and change the way > the "ge" relation works? Hmm ... now that so many things have been talked over I like your Foo- /Foo2-idea more. And automatically installing Foo2 is no problem: If a package you already use needs Foo and an updated version of the package needs Foo2, then Foo2 will automagically [tm] be pulled in. > In essence, the solution I've proposed would turn PEAR into a > repository where multiple kinds of packages that do the same thing > with different APIs co-exist. This is exemplified by the question of > whether File_Passwd that is currently proposed should be released as > File_Passwd2. I didn't realize this until that question was raised. We need to avoid cluttering up the pearweb-interface I think. So we shouldn't have Fill_Passwd and File_Passwd2 in searches / the index (in my oppinion) but only have these different ways to go at the package level - where you can then decide which *version* to use. Also I would prefer to demand that File_Passwd2 starts with 2.0 and File_Passwd will always remain <2, to prevent confusion between File_Passwd-2.4 and File_Passwd2-1.4 or something. What do others think - is this demand needed? Stefan