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

<zitiere wer="Alexey Borzov"> Hi Alexey! Sorry, that I have again to disagree with you! ;) > Tobias Schlitt wrote: >> 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. > I think depending on a package is a matter of trust: if you don't trust me, > why > should you depend on my package? Why should package dependency be a matter of trust? I trust in PEAR, so I can use any stable declared PEAR package and depend on it. So, I really do not have to trust in the developer, but in PEAR to have some controll on it's packages. Do you think any of those users out there trusts in you personally? >> Apart from that, PEAR provides components for usage in applications (for >> what else?) and for that BC breaks have to be avoided. > This is addressed in the ULTIMATE QUESTION. >>>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. > What is Foo_v3: a package with completely new API or Foo with major feature > additions. You can't know without reading the changelog, just as it is now. Why should someone introduce a new major version, when he does no real changes on his package? There would be no need, except, if he has used all minor numbers from the last major, what is very unlikely, IMHO. >>>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. > Just as it is now: you don't want new features, you don't upgrade. But you > don't > need to spend time changing the files if you *do* upgrade. And if you like to use package X, which relies on Foo 1.3 and package Y, which relies on package Foo 2.0? >>> 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'. > But PEAR worked the different way for a significant amount of time. This > will be > a huge BC break. ;] Did it? I do not remember that we had this accident in the past. And I don't believe, that this would be a BC break. It's the way to add functionality without breaking BC. >>> 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. > Please re-read the part about 'Announcing API changes' that is perfectly > implementable without the rest of the RFC. Is it? I mean in respect to package dependencies. >>> 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. > Less choice == good? No, not less choice. More choice! ;) You can decide yourself which package version you'd like to use and even use both in differnet applications on the same host! ;) I think standards are what every project needs and the versioning standard was very spongy until now. Now, that we come to the situation, we'll have to define the standard. >>>4) This may serve as a good excuse to not have tests, QA process and other >>>necessary things. >> What should this excuses look like? > "Well, this is a major version. It may or may not have BC breaks, but as it > is > installed to a different dir I don't really care" > vs. > "Well, this is a major version, but it passes all unit tests" Sorry, but I still do not get the point. Why should anyone avoid documentation/tests/etc. only because his new package directory? I think it's naturally that although deprecated packages have to be maintained several time. Or do we all work like Mic***oft now and tell people after a week "You have to update now to the new version."? There are so many undocumented and untested classes in PEAR, why should this grow only because of new directories. >>>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. > You didn't answer THE ULTIMATE QUESTION. Try again. The point is not on people who want to use similar-API versions of a package parallel. The point is on people using normal PEAR packages short (or long) after BC break. I don't think that major version changes are needed without any significant changes on a package. For that the only reason on upgrading the major version should be an API or heavy functionality break. (You agree with that?) So, what is so bad on having 2 major versions of 1 package installed? It only increases the possibilities of users and developers. > As for PEAR, this should not be allowed. The packages' authors should either > 1) depend on different *packages* (Foo and Foo_v2) > 2) explicitly mark dependency on an old version of package (your users can't > upgrade and they blame *you*, not dependency's author) > 3) make sure your package works with the most recent version. I agree that a package maintainers should make their packages work with the most recent version. But you can not expect them to do this in no time. For that there will allways be times, where users can only use specific packages for their applications. And as PEAR gets older and older, these times will become more and more. 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);');} ?>