David.Comay at Sun.COM wrote:
>
> know about Apache usage is that having a single major version would be
> acceptable but I certainly am open to hearing from others (still need
> to catch up on comments from Matt and Joe on this, I think).

Joe favored supporting concurrent versions.
http://mail.opensolaris.org/pipermail/webstack-discuss/2007-August/000208.html

Matt hasn't really stated a preference.

> One argument for creating a hierarchy to support multiple versions is
> that it would allow transitions to take place using containers on the
> same system.  One could have a production container running Apache
> 2.2.4 and a second container running 2.3.  That said, in talking with
> customers what I've heard is that there is rarely this mixing of
> production and either dev or test environments on the same physical
> system/domain.

I believe the main scenario to consider is
- next minor release family (nevada/S11/whatever) goes out with Apache 2.2.*
  in /usr/apache2, classified as Uncommitted
- wonderful new, but incompatible, Apache 2.4 comes out and there is much
  demand for integrating it
- but it cannot be delivered during the life of that S11 minor release family
  (or alternatively, the same discussion starts all over on whether it 
  should go into /usr/apache2.4 or elsewhere...)


> Leaving aside the /usr hierarchy for the moment (which contains no
> user-editable files and so "moving" the older hierarchy to a new one
> may be fairly easy), what about /etc/apache2 and /var/apache2?  Is
> there a need to create separate versions of this on the same system or
> is the configuration language compatible across different *minor*
> versions?

I don't have enough history on the config language compatibility, but
modules are apparently not necessarily compatible, so if the config
loads an incompatible module the new version wouldn't start/work if it
shares configuration.

My view is that IF the /usr layout supports multiple concurrent
versions, the matching locations in /etc and /var should do the same.



-- 
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems

Reply via email to