Clarify what constitutes API break and what not

[t8m]

DDvO commented Mar 21, 2023

The problem is that basically anything that changes in the public API headers that can potential break a compilation for > anyone is an API break. So until we found that this is very unlikely to break anyone it was considered an API break. Not > sure how to record this and where.

Thanks for your response, which more or less includes a definition of an API break.
Unfortunately, it won't be easy to give simple syntactic rules to correctly and completely determine what will constitute an API break or not.

For instance, the following header file changes do not lead to API breaks:

• whitespace and comment changes
• adding or removing the const qualifier before a primitive (i.e., non-reference) type
• adding or removing the name or changing the name of a function parameter
• adding a declaration
• ...?

I suggest adding something like this to the technical policies, next to the coding style.

[DDvO]

@t8m wrote in openssl/openssl#22304 (comment):

Unfortunately even constifying reference type arguments is nowadays considered an API break because in theory someone could use that function in a function pointer variable.

[arapov]

• Propose a change to stable release policy.