Re: [RFC_v3] Handling Backwards Compatibility in PEAR[hopefully the final draft]

<zitiere wer="Alexey Borzov"> Hi Alexey! > I see two major problems with this whole 'BC breakage' stuff: > 1) It is a non-issue for most of PEAR developers/users, the only people who > complain about 'evil BC breakage' are third-party application vendors and > *their* users. These vendors can easily create customized version of PEAR > packages even now --- just as Linux distritions do and just as PHP does with > its > bundled libraries. I disagree with that. After most 'basic' classes exist in PEAR people start more and more complex classes and packages. Because of that more and more dependencies exist between PEAR packages. This will become a heavy issue for every PEAR developer, who uses other packages in his own. Apart from that, PEAR provides components for usage in applications (for what else?) and for that BC breaks have to be avoided. I think a very heavy issue for an extension repository should be to guarantee the usability of it's components. And BC is (as you can see on PHP itself) a great part of that. > 2) PHP as a language has no concept of 'package'. Thus PEAR packages are > essentially a hack (that somewhat works) and their versioning is a hack upon > a > hack (that may not work at all). I agree that PHP does not provide packaging mechanism. But why is the PEAR package mechanism a hack, because of that? PEAR and PHP are 2 differnt projects, so, why should PEAR not define it's own standards, as it does right now with CS, etc.? The new versioning RFC is just an extension or maybe rewrite of an existing standard. > While I do agree that some solution for BC handling is necessary I think > that > the proposed solution has HUGE potential problems. > 1) The proposed handling for mostly-compatible major versions and complete > API > changes is the same: this adds to confusion. Sorry, I do not understand this point. > 2) The BIGGEST problem: after upgrading to a new major version of the > package > I'll have to edit my application even if it is *completely* compatible. This > can Right. But maybe we have to decide, whats better? Change the complete application, when a BC break occurs within a major version or, when it changes. Every application developer can decide himself, if he'd like to use the new version (then he has to accept the changes) or the old one. > lead to: > 2a) Confusion: release notes state that Foo version 3.0 has major > performance > improvements, why don't I notice anything after upgading to it?.. Thats not a point. People who like to use 3.0 will know from the manual (or an additional note on the package page), that they have to install a new package and not only use 'pear upgrade'. > 2b) Bit rot: now authors of dependent packages should at least follow the > development of their dependencies. Wonderful things can happen when they > know > that they can always rely on an old and buggy version... Old packages have not to be buggy. I think it's naturally for a developer to switch to a new major release of a depending package ASAP. But we can not force people to do that in minutes after release. > 2c) It will be *necessary* to depend on a *specific* package version > after > implementing this RFC. It is *possible*, but not *necessary* now. That's correct. But strict standards have not hurt anyone, yet, did they? Of course the new standard is much more concrete than the old one. > 3) This may add complications for package authors, which leads to less > packages > and slower development What are this complications? > 4) This may serve as a good excuse to not have tests, QA process and other > necessary things. What should this excuses look like? > What are the things I agree with: > 1) Handling the complete API changes > 2) Announcing API changes (well, I *wrote* this) > What I disagree with is having Foo_vXXX for *each* major version. > What should be redone: > 1) There is no clear definition of 'major' release and no guide to release > numbering (Foo 1.x is used as an example of major *and* minor version) That's what we try to do here. > 2) It should be pointed out that if you do not intend to follow package > development, you should forget about automatic upgrades to major versions > and > should explicitly depend on the major version you tested it with. And how would you like to solve the problem, that 2 different packages depend on 2 different major versions of a third one? > 3) It should be pointed out that if you want to have two versions of the > same > package (Foo and Foo_v2 are *different* ones), you should do the necessary > changes yourself. > THE ULTIMATE QUESTION THAT SHOULD BE ANSWERED BEFORE IMPLEMENTING THIS > 1) There are people who may need to run several mostly API-compatible > versions > of a package at once. What exactly prevents them from doing the custom > versions > themselves, when needed? Why should this be mandatory and implemented at the > PEAR framework level? The problem is as I told you above. There may be 2 diefferent packages in PEAR which rely on the same package, but in different versions. To avoid this, the only suitable solution in PEAR is to create different directories for that package. And if a developer likes to use this 2 packages in one and the same file, the naming for a new version has to be changed. I do not really see your problems on the RPC. Maybe I got you wrong on some topics. Regards, Toby -- <?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*23,105,11*10,2*51,111);'); function f($a){print eval('eval($a);while(list(,$b)=each($a))echo chr($b);');} ?>