On 02/20/2018 08:20 PM, William A Rowe Jr wrote:
> > > In other words, modules from one STABLE release to another ARE binary > compatible and do NOT need to be recompiled. > > > This is clearly not true of several recent changes, even though they > impact relatively few third party modules. > > I suggest that since the majority here accepted binary breakage as OK, I do not think that this is the case. I do not accept this and I don't think the majority here does. I am around here for quite a while (effectively shortly before 2.2.x lifted off) and it was always allowed to extend structures at the end. This was always seen as a minor bump and within the set of allowed changes to a minor release. I don't know when these rules were decided, but I grew up with that tribal knowledge and we have a long number of precedent cases for these changes on stable branches. This is not something that was introduced recently. Having said that I admit that it does not match the statement that modules do not need to be recompiled once they have been compiled against a major version and that they should run without the need to recompile against higher minor versions (not necessarily lower ones as they might use added API's). Given that the question to me is how we move forward: 1. We continue as we do now and allow extending structures at the end. We should probably document more prominently that copying / allocating / creating public structures is not allowed and if done can require minor version specific recompiling. 2. We stop allowing extending structures at the end on stable branches. 3. Like 1., but we add _sizeof / _copy functions for each public struct as discussed in the other thread, make the existence of the functions mandatory for every new public struct and advice module authors that they need to leverage them if the want to copy / allocate / create these structures in their modules. We can do 1., 2. or 3. now or set this as the rule for the next major release. Regards Rüdiger
