apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: [discuss] Releasing pre-release APR
Date Mon, 21 Dec 2009 20:16:17 GMT
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

Mime
View raw message