apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
Date Mon, 29 Nov 2004 18:29:15 GMT
At 11:45 AM 11/29/2004, Stas Bekman wrote:
>William A. Rowe, Jr. wrote:
>>At 10:50 AM 11/29/2004, Stas Bekman wrote:
>>
>>>Also should the deprecated macros stay in this file or can those be moved to some
dedicated file to reduce the noise?
>>
>>They stay in place.  During the next major+1 bump, the RM
>>trawls through the files looking for @deprecated, and simply
>>strips them out.  
>
>That's not possible with this particular change, since everything (APR/httpd) still uses
the old macros.

No, it's a requirement when we push major+1.  Then again,
httpd may stay with 1.x, or may have a prerequisite 1.1
(meaning we assume your change is there) or it may even
move to 2.x - in which case we -must- update all occurrences 
within httpd.

There is no reason to keep using the old symbols in apr[-util/-iconv]
so feel free to start migrating those.

>>The way doxygen works, you would not want
>>these moving out of scope to another file.
>
>Is there a way to put them in a different file and tell doxygen that the following entries
really belong to a different file?

1. it isn't pretty and

2. you can't force a user to include another file from minor
   to minor bump.  Their code should keep compiling w/o changes.

Please don't worry that this seems 'polluted' - the next major
bump cleans this all out.  In the meantime, if they look for
these symbols grep APR_FOO include/* they should find the old
and new flavors in the same file, helping them with their own
migration tasks.

Bill 


Mime
View raw message