Re: major shift in versioning possibilities for Pyrus (and as a consequence, PEAR2)

On Jun 26, 2009, at 10:03 PM, Greg Beaver <greg@chiaraquartet.net> wrote:

Hi, I have a potentially controversial new idea about how to solve the related problems of backwards compatibility breaking versions, the proposed namespace standard, and ease of development. First, some background. I've noticed a marked trend to accept the limitations of the tools at hand when deciding what a standard should be, as I remarked in the question on how to do tags in svn versus cvs. This made me start to wonder if my primary objection to the namespace standard might be mitigated. Specifically, the problem is this: in the new namespace standard, package pear2/Blah provides these classes: pear2\blah\Blah pear2\blah\Blah\Driver1 pear2\blah\Blah\Driver2 later on, it becomes necessary for Driver1/Driver2 to have their own life cycles, so they are split off. Suddenly, the classes become: package pear2/Blah: pear2\Blah\Blah package pear2/Blah_Driver1: pear2\blah_driver1\Driver1 package pear2/Blah_Driver2: pear2\blah_driver2\Driver2 User X who has this script: <?php class MyCustomDriver extends pear2\blah\Blah\Driver1 {} ?> blithely runs "php pyrus.phar upgrade Blah" and suddenly has a parse error - unknown class "pear1\blah\Blah\Driver1" Suddenly we have a backwards compatibility break. This, obviously, is not OK, so either the standard needs to be changed to accomodate this possibility, or some other change must come about. I was talking to Brett on the phone yesterday about some related issues in Pyrus and the simple channel server when it occurred to me that one way to solve this kind of an issue would be to use the API version of the package to prevent upgrading to a BC-breaking release. This would actually allow both the risk management of preserving backwards compatibility for users, and the flexible development of designing the next best version of the package. The setting would be introduced in Pyrus and I would call it "paranoid." This would work just like the "verbose" setting in PEAR (and Pyrus), so by passing multiple paranoid options, the paranoia would increase: php pyrus.phar -ppp upgrade Blah would instruct Pyrus to set the paranoia level to 3. Here are the paranoia levels (and what they mean): 1 - don't care (I know what I'm doing, upgrade the dang thing) 2 - no BC breaks (I'm busy, just don't let it break my stuff) 3 - security fixes only (I rely on the API heavily, but I want to keep it secure even if it risks breaking things) 4 - no API changes under any circumstance (I have nightmares terrorists will use my server farm to launch nuclear attacks. I sleep with an uzi under my pillow) in technical terms: 1 - any X.Y.Z API version is fine 2 - X must not change, Y and Z can change (if installed API version is 1.2.3, any 1.Y.Z can be installed) 3 - X and Y cannot change, Z can change (if installed API version is 1.2.3, any 1.2.Z can be installed) 4 - X, Y and Z cannot change. By default, pyrus will set paranoia to "2", so that BC breaking releases are never upgraded to. The user can override this simply through: php pyrus.phar -p upgrade Blah or php pyrus.phar set paranoia 1 to change the default paranoia to "1" Thus in our example above, User X would not be able upgrade to the new release without explicitly requesting it (although Pyrus would notify him that if he were less paranoid, he could upgrade). I am planning to put this in Pyrus, and *not* in PEAR. Too many variables to control for, so... the 6 million dollar question: Do you like this idea? Consider this a quick poll, +1/-1 response a la PHP internals list. If there is pretty much only positive response, I'll see if the PEAR group agrees with a formal RFC they can vote on to change PEAR2 versioning standards. Greg --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

+1 --- The iNazg