>> 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. [ Stealing something I wrote awhile back on the sfwnv-discuss list. ] As ARC'ed in PSARC 2004/676, the module interface has a commitment level of Standard which in the new taxonomy is a committed public interface. However, when this interface was ARCed I believe there was general confusion around incoming open source components and how to map them using the existing interface taxonomy. I believe Standard was chosen even though the Apache Foundation isn't really a standards organization and the API/ABI did not really conform to an interface that had been adopted by "industry convention". Looking back, it seems either External or perhaps a bit more strongly, Evolving would have been a more suitable commitment level. Looking at the current interface taxonomy, it seems Uncommitted is a much more accurate reflection of the commitment level Apache itself puts around the interface but also of the guarantees OpenSolaris can supply around this interface. It's also my belief that customer's expectation around this particular interface are much closer to Uncommitted than Committed. So why not Volatile? Because the guarantees around that commitment level are truly non-existent. I believe we do want to guarantee compatibility of the various versions of Apache for the life of a particular Minor release (once it's gone out the door) but we don't want to ship those versions indefinitely until the next Major release. >> In the currently proposed scenario SUNWsvn will break. > > This runs counter to the "Release Quality All the time" expectation > for ON. > > I'd suggest that this project needs a dependency on a project to update > svn; it should not integrate before such a project. This implies that > either the two projects need to work together or that this project needs > to increase its scope. I believe there is already a CR filed to fix that. I certainly agree that the Apache upgrade needs to make sure that the existing SVN isn't broken by any new APR change or needs to make sure the required updates are made in the same build. dsc
