The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The
last time we discussed it we came up with two solutions:
• Pad the ivar-structures in the classes out to give space to grow
so that it pushes off any ABI compatibility issues as long as
possible. This is why in some APIs, including Cocoa, you see
things like "reserved..." or "private..." variables. These are
there to give room to grow. The disadvantage is that the classes
would then take up more memory as a result.
• Move the ivar-structures out of the classes and replace them with
a void pointer to the actual structure. This has the advantage
that we will never be able to break ABI compatibilty since the sizes
of the structs in the classes will not change... but it also has the
disadvantage of adding a layer of complexity to getting and setting
variables as well as potentially causing unpredictable issues due to
unforseen incompatibilities such as cases where the wrong data is
written into a data structure causing some sort of corruption when
using the wrong version of a library.