Object structure change

[Andreas Ericsson]

On 02/27/2013 03:14 AM, Eric Stanley wrote:
> On 2/26/13 5:05 AM, Andreas Ericsson wrote:
>> On 02/25/2013 07:11 PM, Ton Voon wrote:
>>> Hi,
>>>
>>> Looking through recent commits, I came across 2601, which is a port
>>> of 2600, to fix a downtime issue.
>>>
>>> There is a change to downtime.h to add a new attribute to the
>>> downtime object.
>>>
>>> Am I right in saying that this is a object structure change and thus
>>> will affect the binary compatibility of all broker modules? If so,
>>> this is a problem for Nagios 4 which is in a structure freeze before
>>> release, but more seriously it is a problem in the Nagios 3.4 branch
>>> which will silently break lots of broker modules.
>>>
>> It's an ABI incompatibility, so it requires a recompile of affected
>> modules. No modules use the modified function calls, so for that part
>> it doesn't matter in practical terms, although it's academically
>> horribly (which is to say; It only matters if you're interested in
>> intellectual masturbation). Nagios 3 with the patch should really be
>> released as 3.5 though. For Nagios 4 it's ok to make this change
>> (although I'm not very happy about it).
>>
>> On a side-note, the downtime handling needs to be rewritten more or
>> less completely. I've started it, but the old code has to remain in
>> place (as a shim, preferrably) until 5.0 to retain api compatibility.
>>
>> To clarify, here are the "rules" which we try to adhere to:
>> API change (requires major release):
>>    * remove things from structs
>>    * remove or modify existing functions
>>    * remove existing types
>>    * rename existing types without backwards compatibility hacks
>>     ("#define comment nagios_comment" is the compat hack)
>>
>> ABI change (requires minor release and module recompilation):
>>    * add stuff to structs
>>    * reorder structs
>>
>> API addendum (requires API minor-version extension marker):
>>    * add new types
>>    * add new API's
>>    * add functions to API's
>>
>> Shimming (requires nothing at all):
>>    * Add new API
>>    * Rewrite old API in ABI-compatible way to front the new API
>>    * Use new API in core code
>>
>> Normally, ABI change and API addendum go hand in hand when doing
>> optimizations, and sometimes when doing bugfixes.
>>
> My apologies. I did not realize the trunk was in a code freeze.

Well, it is and it isn't. 4.0 hasn't gone stable yet, so we could
still break everything if it's really necessary. It would be terribly
bad form to do so though, as the amount of testing required is pretty
huge with all the modules and things.

> I've
> been going through the bug list on tracker and fixing things in the core
> 3 code, most of which apply to the core 4 code as well. I will be
> careful until core 4 is released.
> 
> Thanks, too, for the "rules" reminder. I will be happy to make the next
> release 3.5.0 and will include an ABI change notice with the release notes.
> 

That would be great. Thanks :)

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb