Changes after 1.0 which are problematic wrt compatibility

[res]

Several changes have been made to trunk after 1.0 was branched off that break source compatibility, or at leas violate interface versioning rules.

Note that this list does not cover scripting actions, mainly due my lack of expertise in that area. Arguably, scripting actions should treated the same way as API calls - don't change the signature without keeping compatibility for the old version, and no immediate removal (only deprecation + removal at next release).

Major offenses

Compile-breaking changes of method signatures, removal of methods, or removal of complete classes or header files.

• r2423
• r2445
• r2506
• r2517
• r2564

Minor offenses

Non-breaking changes but violating SCF interface versioning rules. (Usually addition of methods.)

• r2407
• r2503
• r2477
• r2533
• r2536
• r2568

[genjix]

r2423: This had been around for a very long time, but is not useful anywhere. It was long overdue removal.

r2506: I accidentally committed some debugging code on my harddrive (removed after).

[res]

Replying to genjix:

r2423: This had been around for a very long time, but is not useful anywhere. It was long overdue removal.

Overdue or not, useful or not: if it's in the public API, there's the risk someone uses it; hence it should be properly removed by following the deprecation protocol.

Yes, compatibility can be a real PITA - but I'd prefer to be thorough and consistent and provide backward compat even for features/behaviours that are, in hindsight, really undesireable.