Matt Ingenthron wrote: > > If we're to come up with a general solution for the stack (I assume we > are, but maybe I'm wrong), we can't have this discussion only around Apache. [...] > I think I agree with both of these, but with the first paragraph, why > are we concerned with whatever definition on forward compatibility *we* > put on the software? We need to state we're tracking what the upstream > communities are shipping, trying to follow their recommendations and > trying to make it easy for users to get the stuff they need. The > community around that component defines it's stability/interfaces, and > we track what they do.
Yes, definitely. Understanding where the upstream components come from is an important part of the effort of including them in OpenSolaris. While the future can't be predicted, the expectations of that community need to be mapped to the way a component is delivered. Some projects have long standing history of backward compatibility similar to Sun's Committed. When integrating such projects there is not much discussion about multiple versions; there is only one and it is known to evolve reliably. Other projects are known to change quickly enough that a single version would mean breaking apps on every update, so multiple versions are easily justified. PHP went that route in 2007/168. I think this discussion finds no good closure with Apache because it is in a grey area. Its minor releases are farther apart and mostly compatible, but still binary incompatible in some ways. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
