RE: [PEAR-DEV] The point (BC breakage)

> > User, curious about version 2.x, reads up on the package page, decides > > to install the package, update the app and after some time, > migrates the > > application to package Foo_v2. > > This (auto-upgrading to minor releases only) can be done with > current PEAR > installer, without introducing another layer of complexity. > > You do know *what* the installer does now on 'PEAR upgrade > PHPUnit', when stable > PHPUnit is installed, don't you? ;] You do *understand* that this has nothing to do with the issue being discussed. The issue being discussed is packages that break BC and the ability to run multiple versions of the same package concurrently. Not whether or not you can install a specific version with the PEAR installer. > > > This does not reflect reality. Nobody in the world has a central > > install of only the core, and user installs of user files. The pear > > command won't even RUN as non-root. This is a totally bogus suggestion. > > Can't pear command be fixed to run as non-root without this RFC? > Thought so. Again. Why is this relevant. I can paint my computer blue, but will that allow me to run multiple concurrent versions of say, DB. Please, if you want to be argumentative for the sake of being argumentative, at least argue about the subject at hand. > > Greg's answer: > > the whole point is that "mostly compatible" versions imply poor design > > on the programmer's part, no? The API should not reach 1.0 until it is > > stable. If that API needs to be changed it is a big deal no matter how > > small the change is. > > What about major feature additions that leave lots of deprecated > stuff lying around? IS BC BROKEN? THE LITMUS TEST IS SIMPLE, NOT COMPLEX, EASY TO UNDERSTAND!!!!!! > > > Alexey says: > > 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 lead to: > > > > Greg's answer: > > Why in God's name would anyone release a new major version if it's > > practically the same as before? This is currently possible in PEAR. > > Please name ANY other major software project that has done > this. Apache? > > PHP? Mysql? Perl? There are no examples. The API is only changed when > > it is clear that there are no workarounds, and it is changed to make > > things significantly better after careful consideration, never lightly. > > Major version bumps in overwhelming majority of projects mean not > 'huge BC > breakage', but 'major improvements'. Think PHP3 -> PHP4. > As for 'currently possible in PEAR', that's why we need a good versioning > scheme, not a way to push half-baked stuff to different dirs. And the move from PHP3 to PHP4 required a lot of code rewriting. There was MAJOR BC BREAKAGE. If you add new features without breaking BC, then no need for a new major version. IS BC BROKEN? THE LITMUS TEST IS SIMPLE, NOT COMPLEX, EASY TO UNDERSTAND!!!!!! > > > Alexey says: > > 2a) Confusion: release notes state that Foo version 3.0 has major > > performance improvements, why don't I notice anything after upgading to > > it?.. > > > > Greg's answer: > > This confusion is easily remedied by the same technique used to read > > about packages in the first place - RTFM. The package page will > > explicitly list the packages, and upon running pear upgrade XXXX the > > installer will list API upgrades as well. > > This wonderful technique works now as well. PEAR installer can be > fixed to show > different upgrade scenarious without adding a level of complexity. > Why add this level? BUT IT CANNOT INSTALL CONCURRENT VERSIONS. WHICH IS THE PROBLEM. AHHHHHHHHHHH!!!!!!!! > > > Alexey says: > > 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... > > > > Greg's answer: > > This makes zero sense. Package authors can now depend on the API of > > their dependencies not changing. Any package author who wants his or > > her package to be used will clearly want to upgrade to the new major > > version if it is better, and that is not any harder to do with the > > current system - still, every usage of the dependency has to be checked > > for BC breakage. I highly disagree with designing PEAR for lazy-asses > > who don't want to write good code :). > > Depending on the API can be done now by depending on version range *and* > enforcing the versioning scheme (see above). > Why add a level of complexity? Because DB depended on an older version of Log than HTML_Quickform (or whatever it was) did. In this case, the breakfix was minor. Simple. But even a series of minor BC breaks may take a while to fix. What do you say to the people coming to PEAR in the mean time, "Well, it works, I swear, but you are going to have to wait a couple of days/weeks until you can actually do anything with it because X changed and now Y and Z that you need cannot run together." And that's not more complex than Y requires X and Z requires X_v2? Send me some of what you have been smoking. Our crack ain't doing it... > > > Greg's main point: > > How often should an API change? RARELY. When it does change, > it should > > be a BIG DEAL(tm). If the API needs to change regularly, this > is simply > > a sign of crappy programming to begin with. Rapid development can and > > should happen (this includes rapid API change) in alpha and beta > > releases preceding a new major version number. This is the whole point > > of alpha and beta. Stable means stable - it doesn't change much, and > > does what it is advertised to do. Users and developers have to be able > > to depend on this, or most of them won't use the package. > > API may change because of a major feature addition. > Having the proposed stuff in PEAR will prevent rapid adoption of "rapidly > developed packages". IS BC BROKEN? THE LITMUS TEST IS SIMPLE, NOT COMPLEX, EASY TO UNDERSTAND!!!!!! > > > PEAR already requires users and developers to do all kinds of things > > like learn how to program in PHP, learn how to set their include_path > > and how it works. Here is the maximum confusion I can see: > > > > User: How do I use MDB 2.0? > > List: pear install MDB_v2 > > User: Do I have to change all my code? > > List: No, but you will have to change some of it. Use this > code as part > > of your application and you won't need to change the classname > > > > class MDB extends MDB_v2{} > > You *do* understand that this user will lose the ability of > running MDB and > MDB_v2 alongside each other after doing this??? And this is the > main selling > point of your RFC. What? Again, send me some of whatever you're smoking. Greg's point was to show you how easy it is to address you main gripe. Thanks, Rob