Jyri Virkki wrote: > James Carlson wrote: > >>> To keep some perspective, what Sun calls volatile sand is what all of >>> these 3rd party applications build their ldap support on and their sky >>> isn't falling from what I'm told. >>> >> In that case, "Volatile" might not be the right classification after >> all. >> > > Perhaps. My sense is that some parts of OpenLDAP APIs are stable (and > some apps use only those parts) while other parts are unpredictable, > but that's just hearsay. It's up to the team owning OpenLDAP (whoever > that is or ends up being) to figure that out. >
My apologies if this is obvious to some of you, but the paragraphs above don't go with the ARC definitions here, does it? As David Comay educated me on once before, "volatile" doesn't say anything about the code/API stability directly. It defines the contract between the dependencies in OpenSolaris, and therefore says something about what the owner will/can do with updates to the package. From a recent doecument <http://opensolaris.org/os/community/on/os_dev_process/> (October 2008): The following are the (new) relevant Public taxonomy levels: Stable: The interface may only change incompatibly in a Major release. Interfaces intended for usage by ISVs and system integrators require this level of support to be useful to these customers. Uncommitted: May only change incompatibly in a Major or Minor release. This is appropriate for some system management facilities and new, untested interfaces. Volatile: May change in any release vehicle. This usually only useful when the interface definition is controlled by a body other than the OpenSolaris community and it is viewed that tracking that community is more important than interface compatibility. Not an Interface: Just a convenience term to label what may appear to a supported interface as not being supported. This is the default classification and this term is only explicitly applied when there is likely to be confusion. The precise terms for the public taxonomy levels is still under discussion, as part of the update to the Interface Taxonomy document. Note that the ability to make an incompatible change in a given release vehicle does not make that a requirement. For example, most interfaces controlled by someone other than the OpenSolaris community are currently classified as Volatile, but synchronization with major incompatibilities introduced by those communities is often deferred until a Minor release is available. It's not clear to me if <http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/> is updated or not. A lot of this is moot for the Apache/PHP<->OpenLDAP since the Apache/PHP projects (which we aim to integrate without core modification as much as possible) already tracks the OpenLDAP project. I can't speak for other components depending on OpenLDAP, but it would seem that trying to artificially hold back any component would actually cause more harm than good. The only difficulty comes in if various components depending on OpenLDAP diverge. Since the interface definition says this thing may change at any time, doesn't that effectively turn the contract around and say "depend on it, but recognize that you'll be responsible for dealing with any updates that happen to hit you". For the vast majority of things in OpenSolaris which would depend on it, this is probably okay since the upstream projects have demonstrated years of being generally in synch or having reasonably stable interfaces between each other. At least, that's my impression since it just works on other platforms. Prior docs said you shouldn't depend upon things classified as volatile at all, but this has been updated for OpenSolaris as I understand it. Then again, I'm not in engineering.... but I do know that there has to be a reasonably simple resolution here. The functional requirement has come up in Sun deployments of PHP. It's an extremely common use case. Again, my apologies if this is obvious to everyone or I'm way off base here. - Matt
