httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Date Mon, 07 Dec 2009 14:45:55 GMT
Joe Orton wrote:
> This is all fine and good but I don't see any implication above that the 
> APR project must enforce its versioning rules on anything other than 
> releases *it voted on* - i.e. releases of APR, rather than releases of 
> httpd.

I'm more than a bit confused.  Does it matter if /usr/lib64/
was installed by a release from apr, or from the httpd or svn projects?  You
are one of the strongest advocates for consistency in shipped, released,
installed binary artifacts and have offered me no end of grief for single-
platform minor behavioral changes.  And certainly I respect you, for your
convictions on this subject.

So let's measurably quantify if this is a molehill;

The httpd project has a feature-detection mechanism of AP_MODULE_MAGIC_AT_LEAST
from ap_mmn.h which reflects the current API, defined by MODULE_MAGIC_NUMBER_MAJOR
provided by apr_version.h, which reflects APR_MAJOR_VERSION, APR_MINOR_VERSION
and APR_PATCH_VERSION.  The version contract declares all features are introduced
at APR_PATCH_VERSION 0 of a given series.  Further, httpd would provide for other
projects to ship httpd's code, AP_SERVER_BASEVENDOR, AP_SERVER_BASEPROJECT and
AP_SERVER_BASEPRODUCT define who has provisioned the code.  APR has no similar
constructs, by design.

Do you disagree with the paragraph above?

Anything that ships from /dist/ must be expected to be installed on some
users' machines, and the code has been released by the respective projects.
Infrastructure has set down ASF-wide policy that /dist/ contains only, and
all release artifacts.  By convention, the ASF does not un-release code.
What exists in persists forever in the  On the other hand, infrastructure has
defined as exactly that, and another
foundation-wide convention defines /dev/ as the developers' working
space, never release space.  There's a clear definition, technically and
legally, between published product and work product.

Do you disagree with the paragraph above?

Then now there should expected to be local installs of a non-APR release
of an APR package by end users, as a published ASF release, without the
user being aware that they have introduced an incompatibility in other
software projects with the bundled flavor of APR.  They believed they
were guinea pigs for an alpha of httpd.  They should not be expected to
anticipate that their installed package may break third party applications
that are testing for APR 1.4 as a prerequisite to a new feature.

Do you disagree with the paragraph above?

Jeff called for apr (or httpd) to offer snapshots as proof-of-readiness
for the next API iteration.  These could have resided at /dev/, or direct
from the /snapshots/ URL.  That sounded like a good idea, and would have
been a reasonable course of action to resolve the previous logjam.
Instead, httpd had chosen to %$@jam APR.  No, I don't really see this as
a technical molehill, but others are free to disagree, since this para
is purely opinion :)

> What and how the APR project chooses to apply API stability rules is 
> something decided by the APR project, not the board or infra.  Do you 
> disagree with that?

Right.  The versioning.html is APR's document, and its a shame when other
projects don't respect the advantages of respecting those guidelines.
Makes Sun's dictatorial supervision of java. seem rather wise.  I'd hope
we can coexist without being dictatorial about it.

Since httpd has introduced a potential for inconsistency, APR project can
work around this by bumping version minor on any further '1.4' changes.
If they are called 1.5, there is no ambiguity.

There's obviously some opportunity at apr 2.0 to refine the versioning
contract at APR.  I'd hope we take advantage of the opportunity to look
at how it's worked for us, and how it's impeded us from moving forwards.

View raw message