David.Comay at sun.com wrote: >>> what's the upgrade story for users going from S10 to S10+1? >> >> >> PSARC 2004/676 (Apache 2) sets expectations this way: >> >> 6. Exported Interfaces >> >> Interface Name Proposed Stability Comments >> >> Apache 2 code base Evolving >> Apache 2 module interface Standard Defined by ASF >> Installed location Evolving >> svc:/application/apache:v2 Stable FMRI >> /var/svc/manifest/application/apache-v2.xml Project Private manifest >> >> >> One transiition mechanosm would be to compile and deliver a complete >> set of 2.2.4 DSO modules and depend on the customer's old httpd.conf >> working with the new server. Unfortunately, I'm not sure how to define >> "complete"; the Blastwave configuration might be a good starting place. > > The customer's old httpd.conf will work with the new server. What will > not work is any third-party modules which haven't been recompiled due > to the APR changing.
The proposed [2.2.4] apache will *can* parse the old [2.0.x] httpd.conf. However, Apache 2.0.x modules might *NOT* load in apache 2.2.4: "API module structure '<module-name>' in file /usr/apache2/libexec/<some-apache-module.so> is garbled - perhaps this is not an Apache module DSO"? This is not a problem for the modules *we* deliver with 2.2.4 (since we will be overwriting the existing 2.0.x modules). It is a problem for external/3rd party/customer modules. Also, old httpd.conf may have to be manually updated, since we are delivering significantly more Apache modules with 2.2.4 than we were delivering in 2.0.x. Any customer-written/customer-built/third-party apache modules compiled and linked against the old [2.0.x] Apache2 will break. About Subversion: svn will need to have a contract with Apache 2.2.4. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
