Ian Holsman wrote:
> [EMAIL PROTECTED] wrote:
>
>> In a message dated 01-09-08 17:43:15 EDT, Ryan wrote...
>>
>>
>>> I know that there aren't many modules for 2.0 today, but at some
>>> point, everybody who has a module for 1.3 will want to port it to
>>> 2.0. I can currently do that in under one hour for even complex
>>> modules. Changing API's like this after we have had 25 releases,
>>> makes that harder.
>>>
>>> Ryan
>>>
>>
>> It's a certainty that when the general public has enough confidence
>> in 2.0 to start porting all the existing modules over ( mod_oas,
>> mod_bandwidth, mod_my_module, God all what else ) they will
>> do so by using the 1.x.x code and just changing as little as
>> possible... which traps all the other API calls in there.
>>
>> It certainly would be best to be very careful about changing
>> any more API's at this point until 2.0 is out the door and
>> flying under its own power. It's almost ready.
>
>
>
> once 2.0 is out the door it is going to be hard/impossible
> to change ANY api, as you will break alot of people's work
> and people will have a hard time upgrading.
> If there is going to be a API change NOW is the time.
> Since the last beta there have been several API changes, and
> have caused 3rd party modules (like mod-proxy, and our internal ones)
> to fail. I expect this in a beta/alpha, not in a released product.
I agree. And in fact, if we were to change nothing else about
apr_table_t between now and 2.0 GA, I'd still want to replace
apr_table_elts with an abstract iterator API. This would
enable us to guarantee to module authors that their code
wouldn't break in the future as the internals of apr_table_t
evolved.
--Brian
