On Tue, Feb 20, 2018 at 2:24 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > 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.
Some structures may be extended and always introduce breakage when a module chooses to copy the structure themself. mod_ftp and mod_cluster are two examples of this. In the case of mod_cluster, it depends on the location of members of the structure, one of which just moved. We perturbed that module with our member shift. BUT because it assumes it knows the len of the structure, it made a bad assumption about doing this on the behalf of a new core module. So it might be a reciprocal breakage. Similarly, bad on mod_wsgi and mod_ftp and similar for creating new structs who cannot predict the size; recompile them. Moving a member in a well-defined structure doesn't fall into this generally accepted change (expanding the length of a struct.) Consider the shm array change doesn't fall into the "it is just a longer struct" example. The proposed mod_dav case is worse yet. If we accept that the API demands the submodule pass the struct to mod_dav, there is no way to distinguish what is going on, and whether this module was written for 2.4.27 or 2.4.33. Worse 2x yet, we guaranteed that no source code revision would be required during 2.4.x. > 2. We stop allowing extending structures at the end on stable branches. I don't think that is realistic. Adding a new member with an acceptable NULL/unknown purpose, and adding 3) as noted below, should generally solve for the case of "module which must be recompiled on each release". > 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. The advantage to _sizeof/_copy and enforcing the "new member default must be ok-to-be-NULL" rule means that mod_cluster, mod_ftp, mod_wsgi and many many other edge-case modules don't need to be recompiled. This situation can be dramatically improved in 2.next/3.0. Ensuring _create() accessors are always provided and demanded to initialize everything that shouldn't default to NULL is the 100% solve. The MMN minor does not help. Nothing suggests whether minor .43 changes the size of any specific member *they* were depending upon; modules may decide to throw up on load if they were compiled against .42 and now are loaded into .43. But that doesn't answer the question of whether something of importance to *that* module has changed.
