Guenter Knauf wrote: > Hi, > William A. Rowe Jr. schrieb: > >> In light of current events, here's a policy statement I'd like to propose >> for consideration (just a discussion item at this point); >> >> The APR project strongly discourages any release of the APR software >> with modifications of the API. This includes shipping ".0-dev" pre >> release source code which has not yet been adopted in an official APR >> release. Any such use is in violation of the Apache APR trademark. >> >> Private releases which include API modifications must not use the name >> Apache APR and must not use the same publicly installed library and header >> file names, or must not be installed or configured to be installed to the >> platform-specific, conventional shared paths such as /usr/bin/, >> /usr/include, >> %windir%\system32 etc. Nothing in this policy precludes the application >> of patches or bug fixes conforming to the released API, although the Apache >> APR project strongly encourages authors to submit such fixes to the >> project. >> >> Snapshots of the current development trees are available for a short period >> of time at http://svn.apache.org/snapshots/, these are not provided for >> redistribution. Developers are encouraged to test against these snapshots >> or the SVN development tree, propose API enhancements and patches to the >> project, and participate in the API discussion. See the guidelines at; >> http://apr.apache.org/patches.html for additional details. >> >> thoughts?/ >> > I think we need a way to distribute alpha releases, just same as what we > do with httpd. > Now what I'm trying to understand is how we really break machines of > alpha testers? First of all I would never test alpha releases on a > production machine, but instead use a dedicated test box for such, and I > also expect everyone else doing so; or that they use a virtual machine, > or a chroot environment (if that works). > Second how do we break things, and what do we break? > The installed libraries are most likely not a problem since they have a > new so name, so nothing links against them. The installed headers are > more a problem, and we should think of a way to workaround this. Isnt it > possible to use versioned directories like 'apr-1.4' instead of just > 'apr'? Then we could probably have more than one installed apr version > side by side ... > Another thing could be to default to static libraries, and only build > shared ones if explicitly specified as argument to configure ... > >
These are all good proposals. I don't know if our versioning rules allow us to suddenly put headers in /usr/include/apr-1.x instead of /usr/include/apr-1.0 as we do now; but we can certainly do this for alpha releases, and possibly just create a symlink to the version-specific include directory for regular releases. And adjust apr-config accordingly. Combined wit the -dev soname idea and the version check in apr_initialize, that's enough safety catches that anyone who manages to shoot themselves in the foot surely did it on purpose. -- Brane
