Matt Ingenthron wrote: > > With some of these things, it'd be very, very hard to say you'll drop > the old ABI/API.
It's not necessarily hard, whether something can be changed ultimately depends on how it was classified. The interfaces for this case (apache2) are mostly being presented as Uncommitted so incompatible change in minor releases is ok. But only minor release... (If they were Committed they'd never change - which implies each release family would have to be in its own location to live on forever. We're only having this discussion because they are Uncommitted.) Major complexity point here is that the release cycle of Apache is entirely disjoint from the cycle of [Open]Solaris. As Apache 2.2.x goes into OS and eventually to S11 as Uncommitted, it can change incompatibly in S12. So if Apache 2.4 comes out well before S12 and is the version everyone wants, it still can't overwrite the 2.2 in S11 updates. That's an argument for the multiple locations. > In any case, we're really following the upstream and > what customers do with it, and they may want us to maintain multiple > ABIs for a long period of time*. Note that there are two aspects here. One is whether to merely allow coexistence the other is whether to actively support multiple versions. In sfw source tree today there is only one apache2 http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/apache2/ which today contains 2.2.3 bits and this project plans to update to 2.2.4 (maybe 2.2.5 if it is out in time, and so on). Assuming multiple install locations, when 2.4 comes out it is possible to: 1) 2.4.x eventually replaces 2.2.n in the source tree [if incompatible, only at a minor release point] and a future os releases include only that 2.4.x; users who upgrade see their 2.2.x install preserved (not overwritten). No further 2.2.x updates are delivered but existing installs are not clobbered. 2) 2.4.x enters the source tree in a different location and both 2.4.x and 2.2.n continue to be actively maintained, built and delivered as well. This doubles all engineering & support costs but provides more options for users. Whether to take on those costs is a business decision of the distribution. Fortunately we here don't necessarily need to know the answer yet; if the layout supports it, it can be decided later. (OTOH the cost of the extra complexity can't be ignored either. If no distribution decides to actively maintain multiple version concurrently, the extra file layout complexity is just clutter complicating both build environments as well as usage (more complex paths, multiple config sets, potential unintended interactions between mismatched libs, etc). No free lunch.) While this is the apache2 case, it's worth pointint out that the php case went with a versioned layout, /usr/php5/[version]/... -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
