Just to make sure we're all one the same page, the change being proposed here has a Minor release binding.
> Can you establish precedent for lowering the commitment level of a > previously committed public interface? Or, can you provide > overwhelming justification for doing so now? Normally, if one wishes > to make this type of change, one reclassifies the existing interfaces > Obsolete and introduces the new ones. The old interfaces are then > removed either in the next minor release at the same time the new ones > are introduced, or left to coexist for one or more minor releases to > allow consumers to transition. See for example LSARC/2000/002 and > LSARC/2006/150. Is there a reason Apache 2.0 and 2.2 cannot coexist > on a host? Effectively, I think Stefan is proposing such a EOF/EOL. For the life of Solaris 10, Apache 2.0.52 (as well as 1.3.33) will be the supported version(s) of Apache in Solaris. The intent is to announce in the next Solaris 10 Update via a release note that the ABI/API exposed by the APR may change in an incompatible fashion in a future (Minor or Major) release of the OS. Keeping the current Apache 2.0.52 around for the life of Nevada while introducing 2.2.4 is certainly an option but I don't think it's warranted. I think customer expectations of this particular interface are that ever so often, modules do need to be recompiled or even recoded. Once a released based off of Nevada has actually been shipped, the current version of Apache 2 would then be locked in stone for that life of that Minor release, unless of course newer versions are completely compatible. As ARC'ed in PSARC 2004/67, 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. dsc
