Re: renaming apr_file_permissions defines
On Fri, Sep 17, 2004 at 09:21:17PM -0500, William A. Rowe, Jr. wrote: At 07:53 PM 9/17/2004, you wrote: and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ Veto - defer for 2.0 There is no reason to wait until 2.0. The versioning guidelines allow us to provide new symbolic names in 1.x versions. As long as APR_REG and friends exist in all 1.x versions, then everything is fine. If 1.1 happens to include a new APR_FILETYPE_REG, then there isn't a problem. IOW, I'd encourage you to reconsider your veto. I don't see the problem that you're trying to prevent. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: renaming apr_file_permissions defines
At 09:15 AM 9/19/2004, Greg Stein wrote: On Fri, Sep 17, 2004 at 09:21:17PM -0500, William A. Rowe, Jr. wrote: At 07:53 PM 9/17/2004, you wrote: and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ Veto - defer for 2.0 There is no reason to wait until 2.0. The versioning guidelines allow us to provide new symbolic names in 1.x versions. As long as APR_REG and friends exist in all 1.x versions, then everything is fine. If 1.1 happens to include a new APR_FILETYPE_REG, then there isn't a problem. This is correct, yes. We need to first branch APR_1_0 development so such patches can be applied to cvs HEAD. IOW, I'd encourage you to reconsider your veto. I don't see the problem that you're trying to prevent. I'm retracting the vetos on these three renames, provided we apply them to APR_1_1, but I'm not 100% comfortable that our own devs want such wordy names. Is it wrong to have both shorthand and the strongly-typed equivalents? In any case, it would not be a good idea to rename these based on minority opinion. I'm +1 for less ambiguous names myself. Bill
Re: renaming apr_file_permissions defines
William A. Rowe, Jr. wrote: Trying for a third week :) . Keep trying :) Several project releases distracted a number of users of this list... Don't worry, someone said that Croats are pretty stubborn :) . For your 1. and 3. and 4. they are fine, simply commit them, +1 to fix in both head and APR_0_9. I don't have a karma to do that. MT. smime.p7s Description: S/MIME Cryptographic Signature
renaming apr_file_permissions defines
and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ with backcompat as following: #ifndef APR_FILEPROT_USETID #define APR_FILEPROT_USETID APR_USETID #endif #ifndef APR_FILEPROT_UREAD #define APR_FILEPROT_UREAD APR_UREAD #endif #ifndef APR_FILEPROT_UWRITE #define APR_FILEPROT_UWRITE APR_UWRITE #endif #ifndef APR_FILEPROT_UEXECUTE #define APR_FILEPROT_UEXECUTE APR_UEXECUTE #endif #ifndef APR_FILEPROT_GSETID #define APR_FILEPROT_GSETID APR_GSETID #endif #ifndef APR_FILEPROT_GREAD #define APR_FILEPROT_GREAD APR_GREAD #endif #ifndef APR_FILEPROT_GWRITE #define APR_FILEPROT_GWRITE APR_GWRITE #endif #ifndef APR_FILEPROT_GEXECUTE #define APR_FILEPROT_GEXECUTE APR_GEXECUTE #endif #ifndef APR_FILEPROT_WSTICKY #define APR_FILEPROT_WSTICKYAPR_WSTICKY #endif #ifndef APR_FILEPROT_WREAD #define APR_FILEPROT_WREAD APR_WREAD #endif #ifndef APR_FILEPROT_WWRITE #define APR_FILEPROT_WWRITE APR_WWRITE #endif #ifndef APR_FILEPROT_WEXECUTE #define APR_FILEPROT_WEXECUTE APR_WEXECUTE #endif #ifndef APR_FILEPROT_OS_DEFAULT #define APR_FILEPROT_OS_DEFAULT APR_OS_DEFAULT #endif #ifndef APR_FILEPROT_FILE_SOURCE_PERMS #define APR_FILEPROT_FILE_SOURCE_PERMS APR_FILEPROT_FILE_SOURCE_PERMS #endif -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_file_permissions defines
At 07:53 PM 9/17/2004, you wrote: and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ Veto - defer for 2.0
