Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <469C97AB.7080901@rowe-clan.net>
Date: Tue, 17 Jul 2007 05:19:23 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.12 (X11/20070530)
MIME-Version: 1.0
To: dev@httpd.apache.org
CC: Mladen Turk <mturk@apache.org>
Subject: Re: svn commit: r556860 - /httpd/httpd/branches/2.2.x/STATUS
References: <20070717092333.195091A981A@eris.apache.org>
In-Reply-To: <20070717092333.195091A981A@eris.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

mturk@apache.org wrote:
> Author: mturk
> Date: Tue Jul 17 02:23:30 2007
> New Revision: 556860
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=556860
> Log:
> Comment the backport concerns for ApacheMonitor
> 
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Tue Jul 17 02:23:30 2007
> @@ -113,6 +113,9 @@
>        wrowe notes post today to list, can we please test for >= VISTA
>        so this doesn't break again upon the release of longhorn server
>        or 'nextgen' windows?
> +      mturk notes: No, because we cannot be sure that any further version
> +      will not break either the service or GUI api, in which case we
> +      would need a separate code depending on the post VISTA versions.

But this is *nonsense*.  We may as well simply have APR stop working at each
new version, if you are that worried about application compatibility.

The simple fact is that *most* applications continue to hum along nicely from
OS rev to OS rev, no matter if we are talking about NT to 2000 to XP to Vista,
or if we are talking about Linux kernel 2.2 to 2.4 to 2.6, or Solaris 2.6 to
2.8 to 8.0 to 10.0.

Of course it *might* break.  But 90% of the time, it won't even load at this
point.  The other 10% of the time, it fails to work.

So do we want to inflict failure on all the success cases to work around 10%
of the unexpected failures to anticipate a fatal change by an OS vendor?
My own 2c is that this isn't the way the httpd project operates.

Planned obsolescence bites.

Bill