The point (BC breakage)

Hi all, There are several simple reasons why Daniel, Alexey's and Pierre's arguments are in my opinion flawed :). Daniel says: Fully agree - the whole ruleset is much too complicated to communicate to all developers. Greg's answer: Which is more complicated? #1) package Foo has version 1.7.0 and new API version 2.1.0. Version 1.7.1 is released to fix a bug that was discovered. User runs: $ pear upgrade Foo upgraded to version 2.1.0 successfully now user's application is completely broken. User emails pear-dev in panic asking how to downgrade. User is told to run: $ pear revert Foo $ pear upgrade Foo-1.7.1 #2) package Foo has version 1.7.0 and new API version Foo_v2 2.1.0. Version 1.7.1 is released to fix a bug that was discovered. User runs: $ pear upgrade Foo upgraded to version 1.7.1 successfully (version 2.1.0 is available as package Foo_v2) 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. I know you said for developers, but let's face it - it's not hard to copy your directory tree from: Foo/ to Foo_v2/ and simply "cvs add/cvs commit" it. Pierre says: I do not. And I think this hoster should think to install only the core. His users can then install whatever packages they need in their tree, both can live together, having core in the common part and userland packages in another, as far as it allows to change the include path (if he does not I wonder why he still get tousands of user ;) ). Greg's answer: 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. Alexey says: 1) The proposed handling for mostly-compatible major versions and complete API changes is the same: this adds to confusion. 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. 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. 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. 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 :). Alexey says: 2c) It will be *necessary* to depend on a *specific* package version after implementing this RFC. It is *possible*, but not *necessary* now. Greg's answer: It is ALREADY necessary - you can't be sure BC is maintained for the subset of a dependency that you use until you've tested it. If your pre-installed package depends on Bar 1.x and the user upgrades to Bar 2.x, it could break your package. The user, in turn, reports a bug in YOUR package - and you have to do twice as much work answering the same damn bug questions over and over until all the users also upgrade your package. With the RFC, this simply cannot happen, ever. Alexey says: 3) This may add complications for package authors, which leads to less packages and slower development Greg's answer: It will lead to saner development, not slower. If you know you have to design a new namespace for API changes, you will think twice before a casual API change, and in addition, you will be encouraged to carefully design API prior to version 1.0.0 so that you aren't forced to rewrite. I've said this before, and I'll say it again. Lazy programmers have no place in PEAR - this is a high quality, STANDARD repository of code for all PHP users. Any developer who has a problem with that SHOULD leave! Alexey says: 4) This may serve as a good excuse to not have tests, QA process and other necessary things. Greg's answer: People who don't do this don't need the RFC as an excuse. As you say, it is only an excuse. 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. 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{} Regards, Greg