On Mon, Feb 19, 2018 at 12:50 PM, Joe Orton <jor...@redhat.com> wrote: > On Sat, Feb 17, 2018 at 02:06:20PM -0000, minf...@apache.org wrote: >> Author: minfrin >> Date: Sat Feb 17 14:06:20 2018 >> New Revision: 1824592 >> >> URL: http://svn.apache.org/viewvc?rev=1824592&view=rev >> Log: >> Update proposal with fix for rpluem/jorton. > > Extending dav_resource still breaks binary backards compat with all(?) > consumers of this API, or am I missing something here? > > Look at what mod_dav_svn does with the struct for an example: > https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?view=markup#l80
(We can continue this from top-thread, but was this question posed to or already considered by dev@svn?) > If breaking backwards compat for module API is fine for 2.4 (and I'm > still generally on the fence about this), I think it should at least be > a "hard" break, e.g. by s/dav_register_provider/dav_register_provider2/. > That way incompatible module combinations break at LoadModule time > rather than with segfaults. This is our Announcement policy; This release builds on and extends the Apache 2.2 API. Modules written for Apache 2.2 will need to be recompiled in order to run with Apache 2.4, and require minimal or no source code changes. http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING When upgrading or installing this version of Apache, please bear in mind that if you intend to use Apache with one of the threaded MPMs (other than the Prefork MPM), you must ensure that any modules you will be using (and the libraries they depend on) are thread-safe. Implication from the above, Modules written for Apache 2.4 will not need to be recompiled in order to run with Apache 2.4. Reading that linked document in reverse; DEVELOPMENT RELEASES, 2.{odd}.{revision} ----------------------------------------- All odd numbered releases designate the 'next' possible stable release, therefore the current development version will always be one greater than the current stable release. Work proceeds on development releases, permitting the modification of the MMN at any time in order to correct deficiencies or shortcomings in the API. This means that modules from one development release to another may not be binary compatible, or may not successfully compile without modification to accomodate the API changes. 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, that the project at MINIMUM now documents every known third party module that must be 1) modified in source or 2) recompiled for binary breakage, and we place that full appendix in every Announcement, and on the main httpd website announcement and download page (followed by some "... and similar modules" caviet, since people may have forked the logic from these third party examples. Or I suggest we back out breaking changes and go back to what this project previously agreed upon and promised for the lifespan of 2.4.x. I don't believe we ever had unanimous consensus, the change to ABI-strict versioning was a majority vote at the end of the day? Changing that policy mid-version seems utterly stupid to me, but I'm tired of people taking personal offense at -1's, so repeating what I've said, I'm neither supporting nor opposing any 2.4.x changes. Simply reminding the list of the basis for our policies.