Re: The point (BC breakage)

On Thu, 25 Sep 2003 11:26:10 -0400 Greg Beaver <greg@chiaraquartet.net> wrote: > 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. Clueless of a waste majority does not mean they are right. Most of admins I meet do not even know what is PEAR, how it works and how cleanly install it. They are not stupid, this is not their jobs. The pear installer can work as non root, see the web installer. The command line as well, it requires some adjustements to the permission (as you run 'make install' with sudo). But once you have the command line it is not really the same situation as described by daniel. People seems to forget: - You do not need the installer to run your app, you do not even need the command line - You can install/copy/alter/whatever your dev station (or you local dev box) to __migrate__, __test__, __valid__, and finally upload the required packages for your app without anything else. That Lukas call bundled packages in his apps. This totally bogus suggestion work well for many hosts. <snip> > 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 :). But you like to design PEAR for lazy-asses people that does not like to test, valid, port their packages/apps? :-) > > 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. Or you can just declare the currentmajorversion-2 deprecated and unmaintained. > 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! And if I have problem with lazy programmers that uses PEAR, have I to leave too? O:-D > 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. I agree here. However between the begin of the BIG DEAL(tm) and its end (the stable big deal with a few weeks of delay:), we may have enough time to follow the evolutions, start to work on our packages/apps to be ready in """time""" if we like the BIG DEAL. > 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. Well, do we have to be a programmers school? What have I to think about a user that do not know PHP and start to use PEAR? or do not know howto program and use PEAR? We cannot solve this kind of problem, imho. > 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{} The maximum crap I can see: pear list Foo_v1 Foo_v2 Foo_v3 Foo_v4 where 30 other packages done by the user depend on every single Foo. Does that make it work on them? not really, the 2 years old release is still installed and heh, he still does not have the time to upgrade his old code (or do not like to work on 2 years old codes). pierre