On Sat, 2002-10-05 at 22:21, Sebastian Bergmann wrote: > Andrei Zmievski wrote: > > I have made PHP_4_3 branch just now. > > Will HEAD become 4.4.0-dev, or 5.0.0-dev? Considering the long release > cycle to be expected I prefer the latter.
I think it's time to head for 5.0 after 4.3, but not without a plan. Below is an outline of what I think is necessary to make PHP 5 happen, without going into each extension/SAPI layer. I have not included extension-specific changes, but try to keep focus on the core, and how to improve PHP 5 development and release processes. PHP has doubled in size since 4.0.0. The release process is taking so long now that it's painful, if it goes much further, people will start burning out trying. This is not a situation we can live with, so this plan addresses both people and code issues that I think are necessary for PHP 5.0 to ever see daylight. Before I start, I want to mention that keeping the scope of 5.0 realistic is crucial. If we didn't think of a feature already, 5.0 shouldn't have it. This is not the time to dream up a feature only because we're doing a new major version. There's been plenty of opportunity for that. Step #1: Do 4.3.x releases from the 4.3 branch We must expect to maintain PHP 4 quite a while longer, and should figure out what the best approach is. I think that just keeping PHP 4 on the 4.3 branch will work, but it depends on how many changes there are in extensions. Moving very active extensions to PECL and using the step #5 approach in subsequent 4.x releases would work. Step #2: Turn HEAD into 5.0.0-dev Zend is replaced by ZE2, all the ZE2-specific branches are merged in. Directory layout should stay the same, to make merging patches between 4.3 and 5.0 easier. The naming will be weird, but it's more manageable this way until the 4.3 commit volume is very low. Step #3: Pickle all extensions! Move all extensions except ext/standard w/dependencies to PECL. Yes, everything. We can add CVS aliases to be able to check out like today easily, but this is the first step towards parallelizing the release process. When extensions are pickled, they are given version numbers (0.5 for experimental, 1.0 for the rest unless something suggests otherwise). Step #4: Getting pickles I will add a "pear import-src" utility to add pickled extensions to your PHP build, so they can be included in static builds. It'll work something like this: $ pear import-src mysql pgsql session xml Downloading mysql-1.0.tgz ... 174,080 bytes Downloading pgsql-1.1.tgz ... 40,960 bytes Downloading session-2.0.tgz ... 30,720 bytes Downloading xml-1.5.1.tgz ... 71,680 bytes Running buildconf... Successfully added these extensions to your build tree: blah blah $ ./configure .... There should be a command for doing the same from CVS too. Step #5: Release Process changes When doing PHP 5 releases, we import the sources of bundled extensions this way in the makedist script. This will leave only the PHP core in the "php[45]" CVS module, which I think is a great starting point for more manageable release cycles than we have now. Step #6: Fix API versioning! As soon as extensions are made available in binary packages, our versioning problems will show their true ugly rear. We should fold the current three API versions into one, and switch to a versioning mechanism that allows using older libraries. If we don't do this, people will have to re-install every separately-installed (through PEAR or otherwise) extension on every upgrade of PHP where the API version changes. If the API change was trivial and did not affect any of our modules, having to rebuild everything is meaningless, and just a waste of peoples' time. This is a problem today, if not on the same scale. This issue still needs a lot of thinking, this is just my reasoning. - Stig -- Stig Sæther Bakken, Fast Search & Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
