Keith M Wesolowski wrote: > No. Apache developers, like providers of many of our > externally-sourced components, have a proven track record of disregard > for, and intentional breakage of, binary compatibility.
Whatever the reasons the Apache developers had to break ABI, they must have considered them to be valid, and justified. The fact is that the Apache developers own the Apache code, and can do whatever they want with it, and with their ABI. "Whatever they want" includes breaking it. > Can you establish precedent for lowering the commitment level of a > previously committed public interface? If this were a Judicial Proceeding, I would assert that I am hereby establishing precedent. Having said that, it was clearly a mistake to classify APR's ABI in 2.0.x as Committed, or Stable, considering the fact that SMI does *NOT* own the Apache code, and cannot enforce any kind of Interface Stability Commitments at apache.org. This classification was made on a series of assumptions. These assumptions were based on someone else's code. I will assert that any Stability Classification above "Uncommited" for code written and controlled outside of SMI is a work of fiction. It creates the perception a contract, but not the existence thereof. This fictitious contract cannot be enforced, given that one of the parties is not only not bound to it, but is completely unaware of it. [Corollary: this fact alone would nullify said hypothetical contract in any Court]. Has apache.org been formally notified when PSARC 2004/676 was submitted and approved ? Was apache.org permitted to comment on the contract ? Did apache.org agree to the terms of this contract ? Does said contract even exist ? This also creates the perception that the ARC submitter for any software controlled outside of SMI, and which proposes to export Stable or Committed Interface Levels, can predict the future. I am not prepared to assert such innate abilities. > Or, can you provide overwhelming justification for doing so now? 1. Performance is orders of magnitude better with mpm-worker than mpm-prefork. 2. LAMP offers both mpm-prefork and mpm-worker, we do not. > 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? This is a valid point: Apache 2.0 and Apache 2.2 *could* coexist, by installing Apache 2.2.4 in /usr/apache2.2, and leaving Apache 2.0.x where it is right now (in /usr/apache2). However this will create additional complexity for those other applications which depend on APR (example: Subversion), and which will now have two choices as to which APR Interface to bind to. It is unclear to me which of the two is the lesser of the evils: - overwrite /usr/apache2 with 2.2.4 and break ABI, but have only one APR Interface to bind to - have both /usr/apache2 and /usr/apache2.2 and create the possibility of application <X> binding to /usr/apache2, application <Y> binding to /usr/apache2.2 and application <Z> binding to both <X> and <Y>. > Sounds like this Solaris experiment my web hosting company conducted > was a waste of time, then. I guess I'll just go back to Red Hat. Which company is that ? URL please. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
