On Fri, Feb 11, 2011 at 9:15 AM, Richard Frith-Macdonald < [email protected]> wrote:
> No ... this sort of stuff rarely actually breaks anything (how often does > anyone want to subclass these things) but we have a 'contract' with our uses > not to break ABI compatibility for stable releases (except very rarely on a > major release). I would really like to be able to make a new minor stable > release (so distributions can adopt it quickly without worrying about > backward compatibility) by copying from svn trunk. So really we want to > make sure that there are no changes in the size of the ivars of existing > classes. This means that either we need to modify things so we are not > using any new ivars in NSDateFormatter and NSNumberFormatter, or our next > stable release really can't contain the latest implementation for these two > classes. The 'padding' instance variable in each class definition is there > precisely so that we can set gs_unused to be a pointer to extra data if we > need to add instance variables without breaking the ABI. > The changes to the formatters were quite invasive, including breaking the default behavior as they now default to 10.4+ behavior. I really couldn't use the padding pointer because I added a lot of new ivars. The only way I could have done anything with it is if I made it a pointer to a structure. Is this what I should have done here? The good news is that I didn't modify anything else but add the new behavior, so a new stable release can be done by simply omitting all the changes I did. Stef
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
