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/libapr-1.so.0.0 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 and MODULE_MAGIC_NUMBER_MINOR. The apr project uses only APR_VERSION_AT_LEAST 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 http://www.apache.org/dist/ persists forever in the http://archive.apache.org/dist/. On the other hand, infrastructure has defined http://svn.apache.org/snapshots/ 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.
